Mikhael Goikhman <[EMAIL PROTECTED]> writes: > On 19 Jul 2001 08:41:05 -0400, Dan Espen wrote: > > > > 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.
I agree with the points you raise, but... If we put stable and unstable things on the same branch, the branch never becomes stable. I'm just trying to figure out some way to avoid our last, too long, release cycle. I don't think we need a branch for every change, just some subset of them. > > > 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've still got users using fvwm1 because they couldn't be bothered converting their .fvwmrc to .fvwm2rc format. If things have to change, I guess I can't stop it. I hope whatever changes are made can be handled with a conversion script. -- 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]
