--On Wednesday, May 29, 2002 4:41 PM +0300 Oded Arbel <[EMAIL PROTECTED]> wrote: > >> Maybe it is also needed to establish of how many of the group >> should support or oppose to it before it is decided to what >> will be added. > > Something like this is needed when you have a one branch development. > when you branch the developers away from the stable release - why bother > ? everyone who has CVS access can commit features as long as care is > take not to break anything and proper notification is done (current > devel-reports is more then enought - just remember to document your > changes in ChangeLog). only conceptual/architectual changes need to be > discussed in the open. Changelog is generated from the cvs commit messages or is it neccessary to do it by hand?? Just wondering, since I thought ChangeLog can be generated from CVS itself. (I could be wrong) > >> >> > - branch the tree now (yesterday would have been a good >> time too ;-) >> >> > and label it 1.2.0. >> >> Why do you already want a branch?? >> Why not putting the releases into a branch?? >> (Just asking) >> Since this way you just can keep developing. >> >> As for a release I would suggest name it 1.2.0 >> Make a branch of it and do new releases as 1.2.x >> Continue development in the main branch for 1.3.y. > > Semantics. I don't mind what you call it, as long as we have a stable > branch and a development branch. Fine, but I would think that you would at least want a different branch for for instance the 1.2.x and the 1.3.y product/stable release. > >> > But for that, before thinking in branches and releases, we should >> > think in the new architecture. >> >> I concur. The only thing is what kind of things do we put on the list. >> You already mentioned some. After what we have to define how indeed. > > Why bother - you can't make architectual changes w/o branching the tree > - you need to get a declared stable release before rewriting the entire > code base, so people will have something to put on their production > servers while the project's next generation is in limbo. What people should put on their production systems is something tested and released as stable. I don't think that people should just take a CVS checkout for the production system. Those poeple take a risk where a released version should have been tested before release. IMHO, that has not much to do with branching. Besdies that I intended to say here that we first need to discuss how the architecture will be and some of those other things. After that we need to decide on the implementation and how to use branches. Maybe some things are having very little impact and thus do not need a special (own) branch. Harrie Internet Management Consulting mailto: [EMAIL PROTECTED] http://www.lisanza.net/
