Home » Eclipse Projects » Orbit » Buckminster provider for Orbit
| Buckminster provider for Orbit [message #9117] |
Wed, 14 February 2007 13:43  |
|
Hi,
I'm setting up a Buckminster provider for the Orbit CVS repository. When
doing so, I create a version converter that converts OSGi versions into
CVS branch names and I need to know more about the semantics used. For
instance, Orbit has branches like:
v1_1
v1_1_0
what is the difference between the two? Apparently this type of
branching only apply to v1_1 and v1_2.
Orbit also has a v4_1_0_1. What's the significance of the last digit?
Kind Regards,
Thomas Hallgren
|
|
|
| Re: Buckminster provider for Orbit [message #9138 is a reply to message #9117] |
Thu, 15 February 2007 07:32  |
 David Williams
Messages: 722
Registered: July 2009 |
Senior Member |
|
|
On Wed, 14 Feb 2007 08:43:37 -0500, Thomas Hallgren <thomas@tada.se> wrote:
> ... and I need to know more about the semantics used. For
> instance, Orbit has branches like:
>
> v1_1
> v1_1_0
>
> what is the difference between the two? Apparently this type of
> branching only apply to v1_1 and v1_2.
>
> Orbit also has a v4_1_0_1. What's the significance of the last digit?
>
Not sure about v1_1 vs. v1_1_0 ... that may be a fluke, or accident and
perhaps one isnt' really used?
The semantics we've agreed to, by convention, is to use the same version numbers
that the third party used when they released. So ... in the case of JUnit, that
version in Orbit is literally the 4.1.0.1 version. Extending that, since OSGi only
treats three places as numeric, we decided to use "0x_qualifier" as the qualifer field,
instead of just "qualifier" ... so, that one would be 4.1.0.01_qualifier for PDE builds.
|
|
|
| Re: Buckminster provider for Orbit [message #9155 is a reply to message #9138] |
Thu, 15 February 2007 21:41 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, David, Thomas,
With regard to the two- or three-digit versions, some third-party libraries
are only released with two-digit version numbers. This is most common with
API specifications. For example, I think the Servlet APIs included in
Orbit are versions 2.3 and 2.4, thus the v2_3 and v2_4 branche names.
Likewise for the W3C bindings for XML specifications, such as the SVG DOM
version 1.2.
Cheers,
Christian
David Williams wrote:
> On Wed, 14 Feb 2007 08:43:37 -0500, Thomas Hallgren <thomas@tada.se>
> wrote:
>
>> ... and I need to know more about the semantics used. For
>> instance, Orbit has branches like:
>>
>> v1_1
>> v1_1_0
>>
>> what is the difference between the two? Apparently this type of
>> branching only apply to v1_1 and v1_2.
>>
>> Orbit also has a v4_1_0_1. What's the significance of the last digit?
>>
>
> Not sure about v1_1 vs. v1_1_0 ... that may be a fluke, or accident and
> perhaps one isnt' really used?
>
> The semantics we've agreed to, by convention, is to use the same version
> numbers that the third party used when they released. So ... in the case
> of JUnit, that version in Orbit is literally the 4.1.0.1 version.
> Extending that, since OSGi only treats three places as numeric, we decided
> to use "0x_qualifier" as the qualifer field, instead of just "qualifier"
> ... so, that one would be 4.1.0.01_qualifier for PDE builds.
|
|
|
| Re: Buckminster provider for Orbit [message #562442 is a reply to message #9117] |
Thu, 15 February 2007 07:32 |
David Williams
Messages: 722
Registered: July 2009 |
Senior Member |
|
|
On Wed, 14 Feb 2007 08:43:37 -0500, Thomas Hallgren <thomas@tada.se> wrote:
> ... and I need to know more about the semantics used. For
> instance, Orbit has branches like:
>
> v1_1
> v1_1_0
>
> what is the difference between the two? Apparently this type of
> branching only apply to v1_1 and v1_2.
>
> Orbit also has a v4_1_0_1. What's the significance of the last digit?
>
Not sure about v1_1 vs. v1_1_0 ... that may be a fluke, or accident and
perhaps one isnt' really used?
The semantics we've agreed to, by convention, is to use the same version numbers
that the third party used when they released. So ... in the case of JUnit, that
version in Orbit is literally the 4.1.0.1 version. Extending that, since OSGi only
treats three places as numeric, we decided to use "0x_qualifier" as the qualifer field,
instead of just "qualifier" ... so, that one would be 4.1.0.01_qualifier for PDE builds.
|
|
|
| Re: Buckminster provider for Orbit [message #562468 is a reply to message #9138] |
Thu, 15 February 2007 21:41 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, David, Thomas,
With regard to the two- or three-digit versions, some third-party libraries
are only released with two-digit version numbers. This is most common with
API specifications. For example, I think the Servlet APIs included in
Orbit are versions 2.3 and 2.4, thus the v2_3 and v2_4 branche names.
Likewise for the W3C bindings for XML specifications, such as the SVG DOM
version 1.2.
Cheers,
Christian
David Williams wrote:
> On Wed, 14 Feb 2007 08:43:37 -0500, Thomas Hallgren <thomas@tada.se>
> wrote:
>
>> ... and I need to know more about the semantics used. For
>> instance, Orbit has branches like:
>>
>> v1_1
>> v1_1_0
>>
>> what is the difference between the two? Apparently this type of
>> branching only apply to v1_1 and v1_2.
>>
>> Orbit also has a v4_1_0_1. What's the significance of the last digit?
>>
>
> Not sure about v1_1 vs. v1_1_0 ... that may be a fluke, or accident and
> perhaps one isnt' really used?
>
> The semantics we've agreed to, by convention, is to use the same version
> numbers that the third party used when they released. So ... in the case
> of JUnit, that version in Orbit is literally the 4.1.0.1 version.
> Extending that, since OSGi only treats three places as numeric, we decided
> to use "0x_qualifier" as the qualifer field, instead of just "qualifier"
> ... so, that one would be 4.1.0.01_qualifier for PDE builds.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:15:44 GMT 2024
Powered by FUDForum. Page generated in 0.04006 seconds |
] 
Search
Help
Register
Login
Home
