geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Spec release numbers
Date Tue, 06 Apr 2010 14:54:00 GMT
On 4/6/2010 10:34 AM, Donald Woods wrote:
> Should we do like the server releases?
> The first new major release uses 2 digits and any follow-on maintenance
> releases introduce the third digit, like -
>    2.1, then 2.1.1, 2.1.2, 2.1.3, ....
>    

That's certainly not what's been done.  Going through the numbers, we 
have a mixture of 1.0-SNAPSHOTS and 1.0.0-SNAPSHOTS for first releases, 
and also a mixture of maintenance release numbers with both 2 and 3 
digits.  Your suggestion sounds fine to me, though the specs really 
never use the middle digit...or even the first one, for that matter!.

> Bigger question, is what does OSGi want?  When we set version ranges
> like [1.0,2.0) does having 1.0 vs. 1.0.1 artifacts matter?
>    

The bundles don't export the version numbers of the spec implementation, 
but only the version number of the interface they implement.  Thus the 
1.0.0 version of geronimo-el_2.2_spec exports the 2.2 version of the el 
packages.  The 1.0.0 version number does not show up there.

Rick
>
> -Donald
>
>
> On 4/6/10 10:05 AM, Rick McGuire wrote:
>    
>> I've been going through and doing some release dry runs on the spec
>> projects, and I've noticed that there is an inconsistency with the
>> release numbering.  Some of the projects use a two level release number
>> (e.g., 1.0), while others use a three level numbering system (e.g.,
>> 1.0.0).  It would be nice to make these consistent, and since we're
>> going to be releasing most of these shortly, now seems like a good time
>> to do this.
>>
>> So, the question I have is which system should we use?  Many projects
>> use a 3-level system, but in the case of the specs, I don't believe we
>> ever really use the middle digit when 3 levels are used.  That generally
>> would only occur when there are functional enhancements to the spec,
>> which generally results in a new subproject getting created to reflect
>> the spec number change.
>>
>> So, should we:
>>
>> [] Convert everything to two-digits
>> [] Convert everything to three-digits
>> [] Leave things the way they are
>>
>> If the consensus is we're fine the way we are, then the next question is
>> whether we should be using two or three digits for newly created spec
>> projects.
>>
>> Rick
>>
>>      
>    


Mime
View raw message