On 11/14/13, 04:12 , Stijn de Witt wrote:
The industry as a whole doesn't treat qualifiers as being less that the version.
In my experience they usually do. E.G they will have -alpha, -beta, -rc1 etc
until finally they drop the qualifier.
Unfortunately there is no consensus so there are also companies that do it
differently...
But in my experience this is the approach that is used most often.
So mostly 1.0.0-alpha is treated as being a lower version than 1.0.0, which in
OSGi is not the case.
It has been my experience that it is common for the qualifier to be used
to indicate patch level or build number or something like that. There
are some qualifiers that are used to be "less than", like -SNAPSHOT and
the ones you mention, but there are others like the ones I mention which
are not. OSGi version numbering did not account for the "less than"
variety, largely because it was coming from the "specification version"
idea from Java.
For now I would advise people against using a qualifier at all.
So how do you version your "snapshot" builds if you don't use a qualifier at
all? Do you bump the micro version on every change in a build?
We work in sprints. The version number stays the same during the sprint. Once
the sprint is over we bump the micro version (or minor/major if we
had breaking changes) and publish to our internal repository. All our devs just
get the updated sources and build from source themselves during the sprint.
So we treat code as in flux during the sprint and only publish stabilized
versions. I can imagine this won't work well if you build and publish nightly.
Maybe I should add a nuance:
Either don't use qualifiers at all, or always use them, including for release
versions (so no 'naked' versions).
Yes, or used an even/odd approach for numbering release/development
versions.
-> richard
-Stijn
-----Original Message-----
From: Daniel McGreal [mailto:[email protected]]
Sent: maandag 11 november 2013 16:17
To: [email protected]
Subject: Re: obr:deploy and bundle versions
Hi,
I'm not sure if this is pertinent. Having not the time to scrutinise the spec,
I've been using the qualifier to indicate distribution/deployment specifics for
my various targets. It's been useful in this regard, where qualifiers are
treated equal in terms of revision amongst the same major.minor..... etc
On 11 Nov 2013, at 15:12, Richard S. Hall wrote:
On 11/11/13, 07:46 , Stijn de Witt wrote:
"for OSGi qualifiers are just sorted so a qualified version is greater"
This is imho a big miss of the OSGi spec.
If you search for 'semantic versioning' you stumble on to this page:
http://semver.org/
Well, the OSGi version model was being defined back in 2004/early 2005...I'm
pretty sure the semantic versioning page didn't exist then.
Tom Preston-Werner of Gravatar/GitHub tried to standardize semantic versioning
across languages and it seems like a very nice attempt. The interesting thing
is that it is virtually identical to the way OSGi defines semantic versioning,
except for one crucial difference... They interpret the qualifier as lowering
the major.minor.micro version, just like Maven does.
This makes a lot of sense. If you look at the way versioning is used throughout
the industry, this most closely matches with the real-world use. The way OSGi
does it is unintuitive and keeps surprising people...
It is not clear what you are saying. The industry as a whole doesn't treat qualifiers as
being less that the version. This is a Maven-specific thing and it only relates to the
qualifier "-SNAPSHOT" which is treated as less than the version. All other
qualifiers are not less than the version.
But yeah, it is probably not something that can ever be changed anymore within
OSGi so probably we are stuck with it...
Yeah, probably. We tried to look into specifying "negative" qualifiers, but it
caused too much pain.
For now I would advise people against using a qualifier at all.
Eclipse seems to survive with qualifiers.
-> richard
-Stijn
-----Original Message-----
From: Richard S. Hall [mailto:[email protected]]
Sent: woensdag 6 november 2013 18:38
To: [email protected]
Subject: Re: obr:deploy and bundle versions
This is a known issue between how Maven interprets the -SNAPSHOT
qualifier and how OSGi interprets version qualifiers. For Maven, the
-SNAPSHOT qualifier is less that the actual version specified, but
for OSGi qualifiers are just sorted so a qualified version is greater
(i.e.,
newer) than an unqualified version.
-> richard
On 11/6/13, 11:48 , Benoît Thiébault wrote:
Hi,
I have been playing with OSGi bundle repositories lately and noticed the
following behaviour.
In Felix (4.0.2), after adding my OBR URL, I type "obr:deploy my-bundle".
On the OBR, I have 2 versions available of this bundle:
- 1.0.7
- 1.0.7-SNAPSHOT
By default, Felix deploys the SNAPSHOT version. Is this an expected behaviour?
I know I can force the use of a given version, but I was surprise by the
default behaviour.
Moreover, if my-bundle depends on a "my-bundle2" bundle, that itself is
available in SNAPSHOT and final versions, the SNAPSHOT is chosen by default...
Thanks for your help,
Kind regards,
Ben
--------------------------------------------------------------------
- To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
