Twitter github

Plug-in Versioning and PDE

When working on Eclipse, you get spoiled as a developer with certain things. I for one, get spoiled silly with the wonderful Java development environment provided by the JDT.

However, another thing I get spoiled by is plug-in versioning. Eclipse actually has versioning guidelines that are reasonable and pretty well followed within the Eclipse Platform. It’s not like where in certain experiences, I’ve known people to make up versioning guidelines without any respect to API and just rev the version when you release, whether things have changed or not. In essence, plug-in versioning is something I believe should be taken seriously and well thought about it before slapping something on (or just leaving the version empty like most people do).

To help with plug-in versioning, I recently dropped code in the next I-build based on an old bug that I had time to hack while on the long plane ride. Here’s the use case…

You’re trying to version a plug-in and open up the properties dialog:

That’s not too helpful… sure you can specify the versions but you aren’t really sure what you’re developing against. Here’s how it looks like after the patch:

Now you can see the versions available in your target and workspace. If you select the ones you’re interested and click match, it will properly construct the minimum and maximum versions:

So, let me know what you think. Also, this means no more excuses when setting up your dependencies and versioning plug-ins, OK :)?

  • Ed Merks

    Chris, I personally have concerns about encoding version ranges directly into the plugins that are checked into CVS.

    The upper bound is a guess, and it’s kind of annoying to simply assume something will stop working when that’s not generally the case. For example, there are plugins downstream from EMF’s plugins that have hard coded ranges and I end up having to hack them as soon as I change a version in EMF. Of course nothing is actually wrong, so it’s just a bad assumption that something will likely be wrong.

    The lower bound also seem problematic to me. I expect such values will grow stale over time and will become invalid. I.e., if I change my plugin can I really be sure I’ll still work with an older version of the things on which I depend without testing that assertion? How many folks actually test and hence verify that their lower bounds are valid?

    For all these reasons, the EMF build automatically inserts lower bounds based on what it’s actually being tests against, and upper bounds based on a pattern relative to what’s actually being tested against. So we’d end up with EMF 2.4 things depending on whatever is the actual version the platform is supplying and setting the upper bound to 4.0 (next higher major version).

  • Ed Merks

    Chris, I personally have concerns about encoding version ranges directly into the plugins that are checked into CVS. The upper bound is a guess, and it’s kind of annoying to simply assume something will stop working when that’s not generally the case. For example, there are plugins downstream from EMF’s plugins that have hard coded ranges and I end up having to hack them as soon as I change a version in EMF. Of course nothing is actually wrong, so it’s just a bad assumption that something will likely be wrong. The lower bound also seem problematic to me. I expect such values will grow stale over time and will become invalid. I.e., if I change my plugin can I really be sure I’ll still work with an older version of the things on which I depend without testing that assertion? How many folks actually test and hence verify that their lower bounds are valid?For all these reasons, the EMF build automatically inserts lower bounds based on what it’s actually being tests against, and upper bounds based on a pattern relative to what’s actually being tested against. So we’d end up with EMF 2.4 things depending on whatever is the actual version the platform is supplying and setting the upper bound to 4.0 (next higher major version).

  • Chris Aniszczyk (zx)

    The upper bound is a guess and by default, when you add a plug-in to your manifest, only the lower bound is set. It’s when you actually right click on the properties of your dependencies that you’re given the option to set the upper bound. In this case, you’re presented with information about what’s in your target to aid you in the complex decision of setting your versioning up properly.

    In the end, there’s only so much magic we can do for the end user as it’s a decision that should rest on their shoulders… PDE can only provide inputs for you to use in making your decision.

  • Chris Aniszczyk (zx)

    The upper bound is a guess and by default, when you add a plug-in to your manifest, only the lower bound is set. It’s when you actually right click on the properties of your dependencies that you’re given the option to set the upper bound. In this case, you’re presented with information about what’s in your target to aid you in the complex decision of setting your versioning up properly.In the end, there’s only so much magic we can do for the end user as it’s a decision that should rest on their shoulders… PDE can only provide inputs for you to use in making your decision.