Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > >>>>> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> On Wed, Jul 03, 2002 at 04:17:23PM +0200, Jean-Marc Lasgouttes > Andre> wrote: Actually I don't even see that as a must. Would be nice, > Andre> though. > >> What would be the new features in 1.3.0 if nother frontend is not > >> operational? > > Andre> Good question. > > Andre> The preview stuff perhaps? > > I thought it was always clear that GUI-I was _the_ 1.3.0 feature.
How strict is the distinction development/release branch anyway? With Linux, it is usual that something is, i.e., "1.3 material". That does not mean that it will be complete and functional with 1.3.0, but that it will not impact the code base in 1.2.x. And in a developers' version (like 1.3.x) usually no attempts are made to keep things out of the code base that are non-functional yet, as long as one can still compile something workable, and as long as no feature freeze has been announced. With that kind of policy, 1.3.0 would mean a basically working release with as much new stuff crammed in that can be put there without compilation/execution failing completely. If it fails completely, no point in assigning a release number. If it basically works, no point in not assigning a release number. Regardless of what just happened to work first. So while most certainly GUI-I _will_ be a required part of 1.4.0 (or 2.0, or whatever stable release is coming up next), I don't see the same requirements for 1.3.0, as long as developers do not get sidetracked too much just by preparing a "release". I mean, if 1.3.0 is to contain everything planned for 1.4.0, you could start a feature freeze right after 1.3.0. Or am I babbling? Would not be too uncommon an occurence... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
