> * x: Major version number > * y: Minor version number > * z: Patch level
it's not only that easy, I would say that java 1.2 and 1.4 are also majors! - just an example. Christoph ----- Original Message ----- From: "Andreas Hochsteger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 30, 2003 8:34 PM Subject: Re: Preparing for 2.2 > Hi! > > What's the intention behind creating different CVS repositories for > different major releases? > Perhaps I'm missing something, but aren't branches and release tags the > mechanism to manage this things in CVS? > > I'm asking because changing the repository has several consequences. > Here are some examples which come to my mind: > * CVS Documentation > * Development tools outside of the Cocoon CVS > * Migration/Integration to/with other version control systems (e.g. > Subversion) > * Statistical and historical analysis is much more difficult > * Cocoon developers, which read the ML less often easily run into problems > > I understand, that this is easier, if some heavy structural changes are > done but is it necessary to do this for every major release? > > Another question: > Why is everybody here talking from major release when just the second > version number (the y in x.y.z) changes? > From many other opensource products I was used to the following > termology (assuming x.y.z as version) > * x: Major version number > * y: Minor version number > * z: Patch level > What terminology are you using? > > Please don't flame me, if I don't understand some of your wording or > organizational conventions. I just want to make clear, that there's a > difference in my understanding. Feel free to explain to me why you did > not choose the standard way (at least as I thought it was). > > Thanks for enlighten me ;-) > > Bye, > Andreas > > Carsten Ziegeler wrote: > > > Finally, our beta (named rc) is out and I will create the announcements > > tomorrow to give the mirrors a little bit of time. > > > > So, by this, it means, we should only apply bug-fixes and docs to the > > repository. > > > > Now, I think this applies only to the core, we can still change the blocks, > > at least the blocks marked as alpha. > > > > We now have to decide how to move on from here in order to start the > > development for 2.2. > > > > We decided to create a new repository for each major version, so this > > would require to create a cocoon-2.2 repository. > > I think this is ok for the cocoon core, but not for the blocks as it > > can be difficult to maintain two different sets. > > > > So I suggest that we create the cocoon-2.2 repository and import > > everything from 2.1 except all blocks. We change the build system > > in 2.2 that it automatically takes during builing the blocks > > from the 2.1 repo (I think it's a property anyway). > > We could also link the docs and not import them in the same way, > > keeping the new repository small in the beginning. > > > > By this we have a simple way of starting development of the "real blocks" > > and all the other nice changes we have in mind. > > > > We have then time to think about how to handle blocks regarding cvs. > > I could imagine to create own repositories for some "bigger" blocks etc. > > But it's best to take small and simple steps for now. > > > > What do you think? > > > > Carsten > > > > > >
