| 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:
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. :-)
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.
|