On 19 Jul 2001 08:41:05 -0400, Dan Espen wrote: > > Olivier Chapuis <[EMAIL PROTECTED]> writes: > > > But we want also to add new features to 2.4.x: at least Xinerama > > support and maybe fvwm-ewmh merging. I think, as Dan suggest in an > > other thread, that we should open a new branch for these. Here one > > reason for this: > > Say that we release 2.4.1 in a few weeks as a bug fix release, then > > we begin to add new features to the 2.4 branch with version 2.4.2. > > Then if we found a serious bug in 2.4.1 we will have some problems > > to release 2.4.2 at once (since 2.4.2 will be beta). > > I suggested opening 2 branches, one for Xinerama, the other for > fvwm-ewmh. > > > So I think that if we want to add new feature to 2.4 we need a > > new branch: 2.5 (We may even want to release 2.6 at some point). > > I do not think that a sequence like 2.5.0, 2.5.1, 2.4.2 would be > > confusing: 2.4.2 will only contains back port of new features from > > the 2.5 branch (the linux kernel use this method). Moreover, if we > > do not want to release 2.6.0 at all and do not want to have a devel > > branch without a stable release at the end we can open 2.9 now, do > > the work we want to do for 2.4.x in 2.9 and back port it. But I think > > that 2.5 is better. > > I don't think numbering the branch 2.5 is a good, mainly because I don't > think we should start a 2.5 series that will take 2 years to release. > > If we name the branches instead of numbering them, we can easily create > merged source trees to test all or some of the branches. When any one > of the branches becomes stable, it can be merged into 2.4.x and released.
Do you suggest this for 2.4.x releases or for later ones as well? So a new named branch should be created for any new feature (or a set of features). For example, 2.4.2 requires 2 named branches, 3.0 requires at least 20 named branches accourding to todo-3.0 and mail archives. What should a developer do? I suppose, have the source trees for all N branches and install them in N locations. Should we release beta version for every branch? If not, how the beta branch becomes stable? What should a user do with all these betas if we do release betas for every branch? Managing N branches (creating, commiting, merging, installing, running) is a nightmare. If the same developers and users work on / test all branches, having more than one beta branch has only disadvantages in my opinion. Correct me if I miss something. If this works, please describe how. > > An other advantage of a 2.5 branch is that doing 3.0.0 can take > > some years. So at some point it will be may be good to release > > 2.6 with some important feature from 2.9 but "compatible" with 2.4. > > I hope we NEVER create an incompatible release. Well, any software theory suggests for evolving projects to do full or partial refactoring from time to time. And to break compatibility without thinking twice if this improves the project. At the end the user benefits from a better program, even he should learn new things. We tried hard to keep 2.4 compatible with 2.2, I don't think this should be necessarily continued to 3.0. Regards, Mikhael. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
