Olivier Chapuis <[EMAIL PROTECTED]> writes: > On Sun, Jul 15, 2001 at 02:38:56PM +0200, Dominik Vogt wrote: > > On Tue, Jul 10, 2001 at 12:24:06AM +0000, Mikhael Goikhman wrote: > > > On 09 Jul 2001 10:37:58 +0200, Dominik Vogt wrote: > > > > > > > > > * changed version from 2.4.0.1 to 2.4.1 > > > > > > > > I wonder how we should number our releases at the moment. We need > > > > some way to have betas with a leading 2.4... since we can't expect > > > > to make a Xinerama release without any betas in between. > > > > > > Well, there are several possible choices: > > > > > > * use 2.4.0.1 (is this understandable that this is beta?) > > > * use 2.4.1 for beta (not much different from the previous) > > > * use 2.4.1-0.20010920 or 2.4.1-beta1 (I would stick to numeric x.y.z) > > > * use temporary names 2.5.x for betas, then return to 2.4.1 > > > > > > We may also fork a branch, do 2.5.x betas and then merge to 2.4.1. > > > But if the plan now is to do stable 2.4.1, forking is not really needed. > > > > Since we won't work in parallel on multiple branches there is no > > need to create one. I vote for the "2.4.1-betaX" approach. > > > > > So my vote is to change to 2.5.0 with or without fork accordingly to the > > > needs, then release next stable 2.4.x, but never 2.6.x. > > > > I agree with the naming schene (2.4/2.5, no 2.6), but a sequence > > 2.5.0, 2.5.1, 2.4.1 would be confusing. > > > > All these depends on what we want to do. > > At the present time only "bugs fix" work is released on 2.4.1 and > this seems to me really reasonable: we may want to release 2.4.1 > in a few weeks without going into a feature-freeze/lot of testing > procedure as some bugs in 2.4.0 are in some sense serious > (libstroke-0.5, FvwmIconMan exiting, compilation failure on some > (old) system).
A week for 2.4.1 seems good. > 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. > 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. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- 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]
