[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cross-project-issues-dev] RE: Feature Versioning& QualifierSuffixes.
|
As Tim and others have suggested, in
an ideal world this is fairly straight-forward. API providers would
never introduce breaking changes, and thus never increment their major
number. Thus downstream plugins could use an "x+1.0.0"
upper bound as described by Ed, and it would never require changing. The
platform will never "move to 4.0" - there may be a release called
4.0, and there may be the odd plugin that eventually require breaking changes
and increment their major version, but individual plugins will never "en
masse" change their major version number. Since breaking changes
will be a rare event, and will almost always require some migration work
for clients anyway, the task of bumping up the upper bound on the version
range shouldn't be too onerous.
I agree with Ed that there is a risk
of the lower bound becoming stale, but I would argue that a stale value
is not useless - it steadily degrades in accuracy but still marks a known
point where the plugin was known to be working (which is much better than
the state of the world before we started using version dependencies). There
has been some discussion of tooling to help flag incorrect lower bounds
but nothing has come of it yet (https://bugs.eclipse.org/bugs/show_bug.cgi?id=121572).
On the other hand, auto-generating the lower bound in the build is
also a reasonable approach, but will exclude some possible configurations
that likely still work.
On the subject of "tight vs. loose"
in the case of plugins that rely on internals, the base platform opted
for "loose". API violations are considered the exception rather
than the norm, and plugins for the most part keep working across minor
releases even if they have the occasional API violation. However,
as Tim says, this could cause failure in random and unexpected ways - but
blame for such failures can correctly be laid on the API violation rather
than on poor choice of version range. I'm not saying this is the
"right" answer, because it's really a trade-off between the risk
of failure and the pain of constantly having to increment version ranges.
As someone who can no longer easily use WTP because I'm on the bleeding
edge of the platform, I suggest you also keep in mind the early adopter
community who jump to each new milestone and are so valuable in providing
bug reports and other feedback.
john
"Tim Wagner"
<twagner@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
14/08/2006 11:53 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> |
|
To
| "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [cross-project-issues-dev] RE: Feature
Versioning&
QualifierSuffixes. |
|
Unfortunately, WTP has several
places where we rely on internal (not API) methods from the base…so in
general, “loose” numbers really are wrong, because the base can and does
change those methods and “breaks” WTP. Ultimately of course the answer
is to eliminate non-API use and then the upper bound could in principle
be left unset, but it’s hard to see a path to that point for a project
as broad as WTP, where there’s always some area that is always at the
very edge of platform services.
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed
Merks
Sent: Monday, August 14, 2006 7:04 AM
To: Cross project issues
Subject: RE: [cross-project-issues-dev] RE: Feature Versioning&
QualifierSuffixes.
Tim,
I'm not sure what the right answers are, but for EMF I was strongly opposed
to putting hard numbers into the MANIFEST.MF files in CVS for several reasons.
Firstly, the upper bound is just a guess. I.e., I guess EMF
will stop working when Eclipse moves to 4.0. But that seems like
a bad guess; if I had to guess, I'd say EMF will always keep working because
the platform won't every break things anyway. When Eclipse does move
to 4.0, I really don't want my first step to be to have to change every
hard coded upper bound to 5.0 just to get the system to try to function.
(Is changing the upper bound in the MANIFEST.MF a change to the plugin
that requires the plugin version of that plugin to be incremented?) The
lower bound is both better and worse than the upper bound. It's better
because it doesn't have to be a guess. It's worse because once you
put in a number, when exactly will you need to change it again? If
you don't ever change it again, it will become stale and useless. I
fully expect that hard coded lower bounds will grow stale and useless during
the next release cycle unless folks actually run tests to verify that their
latest builds really do work with the older dependencies. But who's
going to do all that extra testing to ensure that the bound is valid?
For all these reasons, we went with an approach of generating the numbers
at build time (and we are donating this capability to the base builder).
We set our upper bound for each dependency to be the current major
version number + 1.0.0 and the lower bound to be the first two components
of the current version, i.e., a dependency on version x.y.z will generate
an upper bound of (x+1).0.0 and a lower bound to be x.y.0. This
way we can change the rules as needed and we don't fill CVS with information
that's hard to manage; hard coded numbers will be respected. (Probably
WTP should have set the Eclipse dependencies to be bounded by 4.0, not
3.3.)
Related to this plugin version range question, we've been asked to version
each package in each plugin https://bugs.eclipse.org/bugs/show_bug.cgi?id=152975
but I have an even stronger aversion to this. I'm curious if other
Europa projects will consider doing this?
I'd also like folks to consider this question. Suppose plugin A has
a class C and plugin B has a class D that extends C. If a method
is added to C, A's version will be incremented. But should B's version
be incremented? After all, D now has a new method, even though not
a line of source changed in plugin B.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 969)
"Tim Wagner"
<twagner@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
08/13/2006 03:11 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> |
|
To
| "Cross project issues"
<cross-project-issues-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [cross-project-issues-dev] RE: Feature
Versioning & QualifierSuffixes. |
|
This work is ongoing; WTP will not be usable with platform until we reach
M1. Check out the WTP dev mailing list for details of the process/progress.
There is a deeper question here, as you point out, and I see no way around
the theoretical problem: Either we use “tight” bounds, which means that
in the interim where underlying bits have moved WTP is guaranteed to be
unusable (because version checks fail), or we use “loose” bounds, in
which case WTP *looks* usable but may fail in subtle and bizarre
ways until it has been verified as working again. We chose what seemed
like the conservative approach this time around for end users, but it can
make life miserable for developers who want to be at the HEAD of platform
and WTP simultaneously.
From a process perspective, there are several dates associated with each
milestone as the projects “pile on” in dependency order, and you can’t
get a working Europa stack until the final date of each milestone, usually
2 weeks after the platform ships. If you view that final date as the milestone
“release” date, then end users shouldn’t have to worry about versions,
dependency order, etc. – they just need to wait until everything is ready.
There is no other SLA; combining other versions or operating them ahead
of that date isn’t guaranteed to work (and in WTP’s case, is currently
guaranteed to fail, as you discovered). Thoughts and opinions welcome,
particularly on the “tight vs loose” debate…
-t
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ed Burnette
Sent: Saturday, August 12, 2006 12:58 PM
To: Cross project issues
Subject: [cross-project-issues-dev] RE: Feature Versioning & QualifierSuffixes.
I just installed 3.3M1 and tried to install the other Callisto projects
on it. Right away it bailed with the error:
WST Server Core (1.5.0.v200605151622--1G955G5G7A5GCE) requires feature
"org.eclipse.rcp (3.2.0)", or equivalent.
That's after I clicked 'Add Required'.
Feature org.eclipse.rcp has already been updated to org.eclipse.rcp_3.3.0.v20060801-SVDZ7xum-5-IUJG.
Probably that's because org.eclipse.jface is at version org.eclipse.jface_3.3.0.I20060801-0800
and org.eclipse.ui is at version org.eclipse.ui_3.3.0.I20060803-0010.jar
and org.eclipse.ui.workbench is at org.eclipse.ui.workbench_3.3.0.I20060803-0010.jar
So, is this intentional or not, good or bad? I think it's bad because now
I have no way to run WTP with 3.3M1 until a new WTP is available. Now,
maybe it already is somewhere but it's not on the WTP update site (http://download.eclipse.org/webtools/updates)
or Callisto Discovery site. Even if I were able to find it or hack the
xml files to make it work, that leaves 8 other projects in Callisto that
I might have to track down 3.3 compatible releases for.
I'm not asking for somebody to tell me where to find a 3.3 compatible WTP,
I'm asking about the general cross-project issue with release numbers.
What's Joe User going to do when he gets a new SDK and suddenly his plug-ins
for WTP or BIRT or whatever stop working?
BTW, the default Install/Update preference is "equivalent (1.0.1 ->
1.0.2 - only service increments)". I changed it to "compatible
(1.0.9 -> 1.1.0 - service and minor increments)" but this had no
effect that I could see.
Maybe there needs to be a "version czar" that keeps track of
all eclipse.org feature and plug-in version numbers and version requirement
specifications to make sure they all make sense and play nicely together
(before milestones, if possible). I'm sure there are several committers
that understand the rules, but a lot of people (including me) still don't
get the fine points, despite reading many explainations. See also the thread
below from Andrew Niefer.
--Ed
From: eclipse-dev-bounces@xxxxxxxxxxx [mailto:eclipse-dev-bounces@xxxxxxxxxxx]
On Behalf Of Andrew Niefer
Sent: Thursday, August 10, 2006 12:30 PM
To: eclipse-dev@xxxxxxxxxxx
Subject: [eclipse-dev] Feature Versioning & Qualifier Suffixes.
Hello All,
As work progresses on 3.2.1 and 3.3.0, plug-ins are incrementing their
version numbers from 3.2.0. This is just a little heads up to remember
the features. In order to keep version numbers constantly increasing
it is important to consider the containing feature for any plug-in that
increases its version, particularly when the qualifier changes format (ie
3.2.0.v2006 to 3.2.1.r321_v2006).
The short message is that whenever you change a plug-in's version, you
should let the rel-eng team know so they can update the feature's version
as well.
In the below example, the containing feature had already been incremented
to 3.2.1 the first time one of its plug-ins changed version. For
subsequent changes to other plug-ins, it is sufficient to update the feature's
qualifier.
-Andrew
----- Forwarded by Andrew Niefer/Ottawa/IBM on 08/10/2006 12:06 PM -----
Andrew Niefer/Ottawa/IBM
08/10/2006 12:00 PM
|
To
| David Olsen/Beaverton/IBM@IBMUS
|
cc
| Pascal Rapicault/Ottawa/IBM@IBMCA, Sonia
Dimitrov/Ottawa/IBM@IBMCA
|
Subject
| Re: PDE Build feature version hash issueLink |
|
David,
The hash algorithm only considers the qualifier segment, as such, the decrease
in the suffix is expected in this case. It is assumed that changes
in the first 3 segments of the version will be handled by similar upversioning
in the feature.
I think it is sufficient to update the feature's qualifier, as opposed
to increasing the service number. So the org.eclipse.jdt feature
should have gone
from:
3.2.1.r321_v20060705-V29IdJvl4ZbmoD-
to: 3.2.1.r321_v20060802-R3AKHTrl-ieyxA-
If we were to increase the service number of the feature every time this
happened, it would require a corresponding increase to any containing features.
With independently changing plug-ins, the top level SDK feature would
quickly grow to a large service number. By changing the qualifier
value for the feature (simply a retag and update to the map files), the
full qualifier + suffix stays increasing and containing features should
automatically absorb the change in their qualifier suffixes.
Hope this clears things up,
Andrew
David Olsen/Beaverton/IBM@IBMUS
08/09/2006 08:00 PM
|
To
| Andrew Niefer/Ottawa/IBM
|
cc
| Pascal Rapicault/Ottawa/IBM@IBMCA
|
Subject
| PDE Build feature version hash issue |
|
I may have found an issue with the feature version qualifier hash in PDE
Build. I'm not sure if it is a bug, and if so, whose bug it would
be.
>From build M20060726-0800 to build M20060802-0800 the version number
of the JDT feature org.eclipse.jdt decreased, from
3.2.1.r321_v20060705-V29IdJvl4ZbmoD- to
3.2.1.r321_v20060705-R3AKHTrl-ieyxA-
I went over the version numbers of all the contained plugins with a fine
toothed comb. Every single plugin version number was unchanged or
increased. Most of them were simple qualifier changes, but the plugin
org.eclipse.jdt.launching was more interesting. It went from 3.2.0.v20060605
to 3.2.1.r321_v20060731.
Note that its version number increased, but the qualifier part of
the version decreased ("v2..." to "r3...").
Is the hash algorithm supposed to handle this correctly? Does it
look only at the qualifiers of the included plugins, or at the entire plugin
version? Are qualifiers supposed to be always increasing, even when
other parts of the version number change? Was the third digit of
the feature version number supposed to have been changed because one of
its plugins changed?
The feature.xml files are attached, to save you from tracking them down
yourself.
[attachment "feature-old.xml" deleted by Andrew Niefer/Ottawa/IBM]
[attachment "feature-new.xml" deleted by Andrew Niefer/Ottawa/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev