[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cross-project-issues-dev] RE: Feature Versioning & Qualifier Suffixes.
|
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
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]
