cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <e9625...@student.tuwien.ac.at>
Subject Re: [RT] Versions
Date Tue, 20 Apr 2004 20:50:47 GMT
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?
> 
> 

Mime
View raw message