> 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.

>> 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).

-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]

Reply via email to