Hi, yes, you're right - it's my fault this time, I used the terms in a different meaning. So, if you read this thread and replace "minor" with "patch" and "major" with "minor", we use the general meaning :) Sorry!
BTW, I'm currently working on a first draft of the guide. Carsten > -----Original Message----- > From: Andreas Hochsteger [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 20, 2004 10:51 PM > To: [EMAIL PROTECTED] > Subject: Re: [RT] Versions > > I'm a bit confused about the naming of version number parts. > I always thought, that version numbers are constructed like this: > MAJOR.MINOR.PATCH > > I did some quick google search and found the following pages > which seem to confirm that: > http://apr.apache.org/versioning.html#strategy > http://www.linuxcertified.com/e-learning/linuxplus/html/1_9.html > http://www.elego-software-solutions.com/man/committing-and-rel easing.html > http://edocs.bea.com/wles/docs41/javadocs/JavaAPI/com/bea/secu > rity/ServiceVersion.html > http://protodesign-inc.com/doc/SansGUI/class_schema_version_contro.htm > http://www-unix.mcs.anl.gov/~gawor/jglobus-nightly/doc/org/glo bus/common/Version.html > > In the last discussion about version numbers (it was before > the introduction of the cocoon-2.2 repository) there were the > same misunderstandings as I already pointed out here: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105959008920632&w=2 > > Sorry to be that picky again, but it's hard to follow the > discussions if different people mean different things by > using the same words. > > A versioning guide - like Marc already suggests - would be > really helpful to make these things clear. > > Andreas. > > > Reinhard Poetz schrieb: > > > Carsten Ziegeler wrote: > > > >> Reinhard Poetz wrote: > >> > >> > >>> Carsten Ziegeler wrote: > >>> > >>> > >>> > >>>> <snip/> > >>>> > >>>> > >>>> My opinion is that we should remove deprecated classes (some > >>> > >>> of them) > >>> > >>>> in our 2.1.x branch *now* in order to create a smooth > >>> > >>> transition and to > >>> > >>>> build a better basis for the future development. > >>>> To indicate this, we should update the version number to 2.2 > >>> > >>> *now* in > >>> > >>>> the cocoon-2.1 repository. This would mean that the next > >>> > >>> Cocoon version > >>> > >>>> would be 2.2. If the need for a 2.1.5 arises we could > still make a > >>>> branch. > >>>> We clearly indicate that although we have a major version > >>> > >>> change, there > >>> > >>>> are only minor incompatibilities that shouldn't affect users. > >>>> > >>>> > >>>> > >>> > >>> Who is affected by those changes? What does an upgrade > mean for the > >>> user? > >>> > >>> > >> > >> Good question, thanks Reinhard, I forgot to tell that :) > >> > >> If we remove deprecated classes, users that have developed their > >> application for Cocoon 2.0.x are affected if they are > still using the > >> deprecated classes. If your app is developed for Cocoon 2.1.x, you > >> are not affected. > >> > >> > > > > Following this, why do we need a version change to 2.2 if > 'only' 2.0 > > users, who want to upgrade, are affected. The change from > 2.0 to 2.1 > > was a major version change which _can_ cause some minor > incombatibilites. > > > >> An upgrade for a user means that she just has to replace > the use of > >> the deprecated class with a newer one. So it comes down to using a > >> different interface name and a different method name in some rare > >> cases. The two areas affected here are caching and source > resolving. > >> In both cases, using the new interfaces provides improved features > >> but also improved performance and stability anyway. > >> > >> Another area are the RequestLifeCycle components. They have been > >> introduced in Cocoon 2.0.4 (I think) and we have voted to > remove them > >> in 2.2 again. So if you are using them, you have to use one of the > >> alternatives which is using Contextualizable to get the > object model > >> or the RequestDataStore to store infos. But I guess that > not many are > >> using these interfaces anyway. > >> > >> I would add of course documents on how to update for each area. > >> > >> > > > > Same as above. > > > > IMO we can move on with 2.1.x and remove the depracated classes if > > this is necessary. WDYT? > > > > > >
