|[eclipse-pmc] RE: version numbering semantics|
From: Pascal Rapicault [mailto:Pascal_Rapicault@xxxxxxxxxx]
Sent: Donnerstag, 22. Jänner 2009 04:20
To: Oberhuber, Martin
Cc: Jeff McAffer; Mike Wilson
Subject: Re: version numbering semantics
What I was suggesting during the call was to review the versioning guidelines  because they are eclipse specific when explaining how to specify version ranges. For example we say "Given that all the changes between the version x.0.0 and the version x+1.0.0 excluded must be compatible (given the previous guidelines); the recommended range includes the minimal required version up-to but not including the next major release."
I think that in addition to that, we should have something saying that for bundles not hosted at eclipse, the version range should be written in accordance to the version semantics used by the author of the plug-in (for example if someone was manifesting breaking change by simply changing the second digit, you would need to know). Caveat, of course, most ppl producing the libraries we consume probably have never thought about what they will use as a future version number...
Now in eclipse, because we don't want everyone asking the same question, a description of the version semantic used and/or the range recommended to use could be captured in Orbit.
As for massaging the version number when it gets in Orbit, this is a big no-no to me. This will be too confusing but more importantly would assume that we had somewhat "guaranteed" that the component is actually compatible in the way we claim it is. In your example, how would we guarantee that the runtime behavior of 4.0 (now named 3.8.40) is compatible with 3.8.0?
As for p2 using the original version number and version range matching the semantics of the original version, this would only work at the p2 level and the OSGi level would still suffer from the same issue.
"Oberhuber, Martin" ---01/21/2009 11:32:02 AM---* The problem: icu4j delivers 4.0 without major breakage - Consumers import [3.8,4.0) and get broken
"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Mike Wilson/Ottawa/IBM@IBMCA, "Jeff McAffer" <jeff@xxxxxxxxxxxxxxxxx>
01/21/2009 11:32 AM
version numbering semantics
- The problem: icu4j delivers 4.0 without major breakage - Consumers import [3.8,4.0) and get broken
- Orbit to have a policy that when adding a lib, the version semantics must be specified somehow (in order to educate consumers that they better consume [3.8,10.0) for instance
- Have version numbers "translated" when bundling for orbit, e.g. bundle icu4j 4.0 in orbit as version 3.8.40
- Have p2 translate "external" semantics
Anything to be discussed on the orbit-dev mailing list or on the architecture council?
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
Back to the top