On Thu, Jul 19, 2001 at 08:41:05AM -0400, Dan Espen wrote: > 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.
If we do make the changes planned for 3.0 - e.g. removing the TitleStyle, BorderStyle and ButtonStyle commands - 3.0 *will* be incompatible. It wouldn't make sense to clean up the syntax for simplicity and the try to keep compatibility. 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]
