cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Versions
Date Wed, 21 Apr 2004 06:33:51 GMT
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?
> > 
> > 
> 
> 


Mime
View raw message