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
