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]