Catalogue improvements: OSGi feature proposal; version numbers

[Aled Sage <al...@gmail.com>]

Hi all,

What format should we use for version numbers is the brooklyn catalog 
(e.g. for versioned blueprints and for referenced OSGi bundles)?

I see two options:

 1. Use OSGi versioning everywhere.
 2. OSGi versioning for the OSGi bundles it references, but use
    semver.org for the catalog item versions.

For option (2), we'd end up with a yaml catalog item file containing 
both the item's version number and references to bundle version numbers 
- i.e. using a different scheme for the different numbers appearing in 
the same file. That is off-putting.
But I do so like semver.org!

Thoughts?

---
My favourite versioning is semver.org [1], but OSGi uses a slightly 
different versioning scheme in how it treats the qualifier versus 
semver's pre-release suffix [2,3].

In OSGi, 1.0.0-M1 is not valid, but 1.0.0.M1 would be. However, 1.0.0 < 
1.0.0.M1 (i.e. the qualifier is part of the version number rather than 
being for pre-release). The OSGi qualifier is compared with 
String.compareTo, ignoring case; the major minor and micro components 
are compared as integers.

In semver, 1.0.0 > 1.0.0-M1 because the "-M1" tells us it is 
pre-release. In semver, 1.0.0.M1 is not valid.

Aled

[1] http://semver.org/
[2] 
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html#Version(java.lang.String)
[3] 
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html#compareTo(org.osgi.framework.Version)


On 30/06/2014 15:15, Aled Sage wrote:
> Thanks Sam,
>
> I've also created a jira issue (feature) for this work: issue 
> https://issues.apache.org/jira/browse/BROOKLYN-13
>
> Aled

Re: Catalogue improvements: OSGi feature proposal; version numbers

[Sam Corbett <sa...@cloudsoftcorp.com>]

My initial instinct is to keep to one versioning scheme. Option 2 would 
surely be a surprise to users.

Alternatively, are entries in the catalogue always going to be for 
things that use OSGi bundles as dependencies? If Brooklyn accepted 
catalogue entries for non-Java blueprints the OSGi-version-only decision 
would make less sense.

I could imagine blueprints in Python referring to modules to install 
with pip, or ones in Ruby to gems, etc. I appreciate anything like that 
is a long way away..

Sam

01/07/2014 15:10, Aled Sage wrote:
> Hi all,
>
> What format should we use for version numbers is the brooklyn catalog 
> (e.g. for versioned blueprints and for referenced OSGi bundles)?
>
> I see two options:
>
> 1. Use OSGi versioning everywhere.
> 2. OSGi versioning for the OSGi bundles it references, but use
>    semver.org for the catalog item versions.
>
> For option (2), we'd end up with a yaml catalog item file containing 
> both the item's version number and references to bundle version 
> numbers - i.e. using a different scheme for the different numbers 
> appearing in the same file. That is off-putting.
> But I do so like semver.org!
>
> Thoughts?
>
> ---
> My favourite versioning is semver.org [1], but OSGi uses a slightly 
> different versioning scheme in how it treats the qualifier versus 
> semver's pre-release suffix [2,3].
>
> In OSGi, 1.0.0-M1 is not valid, but 1.0.0.M1 would be. However, 1.0.0 
> < 1.0.0.M1 (i.e. the qualifier is part of the version number rather 
> than being for pre-release). The OSGi qualifier is compared with 
> String.compareTo, ignoring case; the major minor and micro components 
> are compared as integers.
>
> In semver, 1.0.0 > 1.0.0-M1 because the "-M1" tells us it is 
> pre-release. In semver, 1.0.0.M1 is not valid.
>
> Aled
>
> [1] http://semver.org/
> [2] 
> http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html#Version(java.lang.String)
> [3] 
> http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html#compareTo(org.osgi.framework.Version)
>
>
> On 30/06/2014 15:15, Aled Sage wrote:
>> Thanks Sam,
>>
>> I've also created a jira issue (feature) for this work: issue 
>> https://issues.apache.org/jira/browse/BROOKLYN-13
>>
>> Aled
>
>