Re: [cdt-dev] Update CDT feature/plugin versions for Helios SR1 and Ind

[Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>]

I am voting for #2

On Tue, Jul 27, 2010 at 10:19 AM, Marc Khouzam
<marc.khouzam@xxxxxxxxxxxx> wrote:
> 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
>
>
> ________________________________
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Christian W. Damus
> Sent: Monday, July 26, 2010 4:06 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Update CDT feature/plugin versions for Helios SR1 and
> Indigo releases
>
> 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
>
>
> ________________________________
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Vivian Kong
> Sent: Tuesday, June 29, 2010 10:53 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] Update CDT feature/plugin versions for Helios SR1 and
> Indigo releases
>
> 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
>
>
> --
> Christian W. Damus
> Software Developer, IDE Team
> QNX Software Systems
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>