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]
