river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Release versioning
Date Sun, 04 Oct 2009 18:07:31 GMT
This release includes a new package and integrated testing, so I'd say 
it's safe to go for the 2.2

The org.apache.river namechange will cause some breakage, so it's safe 
to call it 3.0, 3.0 will include some java 5 constructs also.

Cheers,

Peter.

Jonathan Costers wrote:
> Actually, when I carefully read the posted definitions, what we are
> about to release really more looks like a point release...
>
> So 2.1.2?
>
> And when we do the com.sun.jini -> org.apache.river namechange, move to
> 2.2?
>
> Just a thought..
>
> Op zondag 04-10-2009 om 21:42 uur [tijdzone +1000], schreef Peter
> Firmstone:
>   
>> +1
>>
>> Peter.
>>
>> Jonathan Costers wrote:
>>     
>>> What about this:
>>>
>>> - Previous release was 2.1.1 (AR1).
>>>   -> apache-river-2.1.1-incubating
>>>
>>> - We are developing for 2.2, hence all Hudson builds are named
>>> 2.2-SNAPSHOT
>>>   -> apache-river-2.2-SNAPSHOT-incubating
>>>
>>> - When we release 2.2 (AR2) we change version to 2.2
>>>   -> apache-river-2.2-incubating
>>>
>>> - After building 2.2, we set version to 2.2.1-SNAPSHOT (or whatever
>>> version we decide we should go to after 2.2)
>>>   -> apache-river-2.2.1-SNAPSHOT-incubating
>>>
>>> This would be compatible with Maven repositories, allowing us to publish
>>> all snapshot builds. It would IMHO also make more sense then what we are
>>> doing now (i.e. all snapshot builds are currently still named 2.1.1).
>>>
>>> Best
>>> Jonathan
>>>
>>> Op zaterdag 03-10-2009 om 15:24 uur [tijdzone +1000], schreef Peter
>>> Firmstone:
>>>   
>>>       
>>>> Ok, how about the following release version scheme?
>>>>
>>>> Major.Minor.Point
>>>>
>>>> -Point Release:     No API changes, bug fixes, internal implementation
>>>>                     refactoring only.
>>>> -Minor Release:     Expanded API for existing packages, new utility 
>>>> packages,
>>>>                     no breaking of API backward compatibility.
>>>>                     Bug fixes, reimplementation or refactoring of existing
>>>>                     API functionality.
>>>> -Major Release:     New Features, Packages & API, where those API 
>>>> Changes could
>>>>                     potentially break backward compatibility and require
>>>>                     recompilation for existing applications.
>>>>
>>>> I'm not suggesting we break backward compatibility, just that if we do, 
>>>> it'll definitely be a major point release.
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>     
>>>>         
>>>   
>>>       
>
>
>   


Mime
View raw message