[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipse-pmc] RE: version numbering semantics
|
Hi all,
thanks for your comments about version numbering.
I
have filed Orbit bug 262015 [1]
asking for an infrastructure to announce version semantics of its
bundles;
and, AC bug 262018 [2]
depending on that one, to revise the version numbering guidelines such that its
text takes external libs (and the upcoming Orbit infrastructure) into
account.
Please join the discussion on these bugs if you are
interested.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
What I was suggesting during the call was to review the versioning
guidelines [1] 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.
PaScaL
[1] http://wiki.eclipse.org/Version_Numbering
"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
From: |
"Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx> |
To: |
Pascal
Rapicault/Ottawa/IBM@IBMCA |
Cc: |
Mike
Wilson/Ottawa/IBM@IBMCA, "Jeff McAffer"
<jeff@xxxxxxxxxxxxxxxxx> |
Date: |
01/21/2009 11:32 AM |
Subject: |
version numbering
semantics |
- The problem: icu4j delivers 4.0 without major
breakage - Consumers import [3.8,4.0) and get broken
- Ideas:
- 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
else?
Anything to be discussed on the orbit-dev
mailing list or on the architecture council?
Cheers,
--
Martin
Oberhuber, Senior Member of
Technical Staff, Wind
River
Target Management Project
Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
