On Sat, Jul 21, 2001 at 07:24:27PM +0000, Mikhael Goikhman wrote: > 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.
I'm not the biggest fan of branches. The past has shown that we can manage fvwm with only two branches: the development branch and the stable branch. I see no need to break this pattern anytime soon. I am dead determined to include Xinerama support into 2.4.1 along with the first bunch of bug fixes. If we don't make a religion of our nice new release numbering scheme (2nd digit odd = development, even = stable) there should not be any problem. Now that I managed to get my Xinerama setup running again (had a lot of trouble with mail and X11 in the past few weeks), I am working hard on that feature. After that, it's probably best not to start with the disrupting features. There is a huge backlog of small enhancements and fixes, so there is no need to start with the syntax rewrites in the near future. Perhaps even a 2.6 release in between may be in order. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
