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:e9625392@student.tuwien.ac.at]
> Sent: Tuesday, April 20, 2004 10:51 PM
> To: dev@cocoon.apache.org
> 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?
> >
> >
>
>
|