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-releasing.html
http://edocs.bea.com/wles/docs41/javadocs/JavaAPI/com/bea/security/ServiceVersion.html
http://protodesign-inc.com/doc/SansGUI/class_schema_version_contro.htm
http://www-unix.mcs.anl.gov/~gawor/jglobus-nightly/doc/org/globus/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?
