Thanks for the info. If I understand correctly, your
suggestion is to require the latest version of the plugins.
I think that makes sense and that we have been making that
assumption in CDT without enforcing it.
I dont' believe anyone expexts to have a feature of CDT 7.0
use a plugin of CDT 6.0
So, looking at the Dependencies editor of feature.xml, I
can see that we can choose between:
Equivalent
Compatible
Greater or Equal
Perfect
<none> (no version specificed)
There is also a check box labeled "Recompute when feature
plug-ins change"
but I couldn't figure out what it actually does and
when.
My first thought is that we should do one of two
things:
1- Use "Perfect", which I assume means we require one
specific version of the plugin.
This will require us to change the version in the feature
at the same time as when we change
it in the plugin. We can detect errors quickly as
soon as someone try to install a build.
2- Don't specify a version at all in the dependency.
This requires less work on our part
(no need to maintain versions in feature.xml) but then the
feature will accept to be installed
with any version of the required plugin. At first
glance, this does not seem too bad, since
we kind of were doing that already in CDT (not really
paying attention to the versions
in feature.xml)
If we want to go with #2, we could clean up all the
feature.xml files to remove all versions
in the dependencies.
Finally, I assume that having a dependency on the same
plugin twice but with two
versions is a mistake. In
platform-feature/feature.xml I see, for example:
<import
plugin="org.eclipse.cdt.core" version="5.0.0"
match="compatible"/>
<import
plugin="org.eclipse.cdt.core" version="5.1.0"
match="greaterOrEqual"/>
<import
plugin="org.eclipse.cdt.core" version="5.2.0"
match="compatible"/>
I guess we should clean that up and replace with
either
(#1) <import
plugin="org.eclipse.cdt.core" version="5.3.0"
match="perfect"/>
or
(#2) <import
plugin="org.eclipse.cdt.core"/>
I vote for trying out #2.
What do people think?
Marc
Hi, Marc,
See some replies in-line,
below.
HTH,
Christian
On 26/07/10 03:11 PM, Marc
Khouzam wrote:
Hi,
I'm new to feature handling for our
development. I'd like to know what I should do to features, when I
update the version of a plugin.
Looking a the mail below,
1- I should make sure the feature that imports that
plugin has a new version since CDT 7.0
(either minor or major, depending
on the plugin changes part of that
feature).
Could there be more than one feature
impacted?
I think that all features that
have plug-ins whose API re-exports the API of your updated dependency will
need need to update their version numbers according to the kind of update
(minor/major).
Unless you are willing to accept the burden of
continuing to test the feature with the old version of the dependency, to
ensure that it still works. :-)
2- When changing a feature version, I
need to update the cdt.releng plugin buildsite.xml to
remove
the old feature version and put the new
one
But also, I think,
3- I must check feature.xml and somehow deal with
the "Dependencies" tab. This is unclear to me.
Some of the dependencies use "Compatible", some
"Greater or Equal", and some fo the versions
of the plugins are older than the actual
plugin. Should I keep those versions the same as the
plugins?
Which type of dependency should we use?
"Compatible" or "Greater or Equal", or is there a smart
way to choose one of the
two?
If you're updating a bundle that your
feature requires to a newer version, if the feature will continue to work with
the older version of that bundle (i.e., you're not using new API from that
bundle), then you don't have to change the dependency version. However,
this implies a burden of continuing to test that feature with the old bundle
version, which I don't think any sane person would do.
So, it's best to
update the minimum required version of the bundle in your feature
manifest.
IMHO, "greater or equal" should never be used, because this
accepts API breakages when bundle dependencies change their major version
parts. How could one test *in advance* that those future versions will
still work, i.e., that any potential API breakage will not impact this
feature? I think "compatible" should be preferred.
All of this
applies equally to the dependency version ranges in bundle-to-bundle
dependencies. In fact, if you actively manage dependencies only at the
bundle level, then the Feature Manifest Editor can compute the feature-level
bundle dependencies for you (there's a little button for that in the
editor).
When I was with the EMF project, we took this to the extreme
by *always* updating the lower-bound of all dependency ranges to the actual
major.minor version of every bundle, because we knew that was the only
configuration we could reasonably test. It didn't matter that, for
example, EMF 2.5 could actually run on Eclipse 3.4. We built and tested
with Eclipse 3.5, so that was the dependency lower bound. In practice, I
think this was the right approach, because otherwise users could upgrade in
the field to configurations that we hadn't tested, and could actually break in
ways we hadn't anticipated. It somewhat limits the flexibility of the
dependency and update mechanism, but at least it was safe.
Thanks for any guidance.
Marc
Hi everyone,
We need to update the feature/plugin version
numbers for the Helios SR1 (cdt_7_0) and Indigo (HEAD)
releases.
I've made an attempt to update the feature versions based
on any plugin version number changes after Helios. I need everyone's help
to keep the feature numbers up-to-date so please be sure to update the
associated feature version as you update the version number of your
plugins. This is done in the feature's feature.xml as well as
buildsite.xml in org.eclipse.cdt.releng so our update site is up-to-date
as well. You can find the org.eclipse.cdt.releng plugin under
org.eclipse.cdt/all in CVS.
For changes I've made so far, please
see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318337
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318338
Thanks!
Regards,
Vivian
Kong
IBM Eclipse CDT
IBM Canada Toronto Lab
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev