You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2010/04/06 16:05:37 UTC
Spec release numbers
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
Re: Spec release numbers
Posted by Rick McGuire <ri...@gmail.com>.
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, ....
>
For now, I'd like to focus on the central question I asked originally,
which was about getting some consistency in the spec version numbering.
I like Donald's suggestion. If implemented, here are the things that
would change:
Changing from 1.0.0 to 1.0:
geronimo-ccpp_1.0_spec
geronimo-ejb_3.1_spec
geronimo-interceptor_1.1_spec
geronimo-jaxrs_1.1_spec
geronimo-osgi-support
geronimo-stax-api_1.2_spec
NOTE: If the changes goes the other way (1.0 changed to 1.0.0), a
larger number of specs need to be changed.
Changing from 2-digit release numbers to 3 digit:
geronimo-jaspic_1.0_spec (changes from 1.1 to 1.0.1)
geronimo-javaee-deployment_1.1MR3_spec (changes from 1.1 to 1.0.1)
geronimo-javamail_1.4_spec (changes from 1.7 to 1.0.7). A corresponding
change will be made with the provider and uber jar.
geronimo-jpa_2.0_spec (changes from 1.1 to 1.0.1)
I'd like to start the release process for the spec jars very early next
week, so I'd like to make this change this week. If there are no
objections to these changes, I'll make them tomorrow morning.
Rick
> 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?
>
>
> -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
>>
>>
>
Re: Spec release numbers
Posted by Rick McGuire <ri...@gmail.com>.
On 4/6/2010 2:23 PM, David Jencks wrote:
> On Apr 6, 2010, at 7:54 AM, Rick McGuire wrote:
>
>
>> 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.
>>
> IIUC osgi expects to come up with some package versions for ee spec apis that has no relationship to the ee spec version but does follow osgi version semantics. So, anything we publish now will be at least 90% wrong and apt to produce problems if it's released into the wild for everyone. The only case I'm aware of where there's been some conclusion is to version the jpa 2 api at 1.1.
>
> Maybe we should not version the packages in the jars until osgi firms up its idea of what they should be????
>
> thanks
> david jencks
>
>
I would seriously not recommend that...most of the build errors I've had
to deal with only got sorted out by explicitly specifying the package
versions. And unfortunately, many of the bundles we pick up from other
places are importing those same packages based on the java EE version
numbers, not what the OSGi Alliance has decided to tag them as. Damned
if you do, damned if you don't :-(
Rick
>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: Spec release numbers
Posted by David Jencks <da...@yahoo.com>.
On Apr 6, 2010, at 7:54 AM, Rick McGuire wrote:
> 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.
IIUC osgi expects to come up with some package versions for ee spec apis that has no relationship to the ee spec version but does follow osgi version semantics. So, anything we publish now will be at least 90% wrong and apt to produce problems if it's released into the wild for everyone. The only case I'm aware of where there's been some conclusion is to version the jpa 2 api at 1.1.
Maybe we should not version the packages in the jars until osgi firms up its idea of what they should be????
thanks
david jencks
>
> 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
>>>
>>>
>>
>
Re: Spec release numbers
Posted by Rick McGuire <ri...@gmail.com>.
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
>>
>>
>
Re: Spec release numbers
Posted by Donald Woods <dw...@apache.org>.
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, ....
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?
-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
>