Re: [cross-project-issues-dev] Bundle Version Management

[Ed Merks <ed.merks@xxxxxxxxx>]

John,

Comments below.

On 17/08/2012 3:52 PM, John Arthorne wrote:

Ed Merks <ed.merks@xxxxxxxxx> wrote on 08/17/2012 08:49:16 AM:
> Eike and I have been working on a tool for helping manage plugin and
> feature versions (as well as other types of consistency checks).  

Sounds great! We had a tool like this in Platform project but it was broken a couple of years ago and we never got around to fixing it.

> 1.  Can anyone comment on why we've pretty much all ended up hard
> coding the license feature version rather than using 0.0.0 like we
> do for include and plugin declarations?  

My memory is fuzzy on this, but I think one of the considerations here was that you wouldn't want your features to end up with a different license "for free" without it being a deliberate choice.

Well, we specify exactly the feature ID for the license so it ought not to ever change for free.  Also, with our version tool, if the license feature changes, its version number must be changed, and once that's change, every feature that includes it must change its version number too, in a way that's consistent with the version change in the license, i.e., if the license change is a micro change, the including features need a micro increment, if it's a minor change, the including features need a minor increment.

If an EPL v2.0 came out, we couldn't have projects automatically picking it up.

No, we'd have to change each of our license features, i.e., the one for EMF the EMF project's features.

Also licenses tend to evolve differently than other dependencies. When they change, you generally want to change every singe feature at once so a search & replace is very easy to do.

The versioning tool would tell you that other features need increment and why, i.e., because of the increment of a particular dependency.

Having said all that, you could use 0.0.0 if you were very careful about ensuring only the right license was available at build time.

I imagine every project has their own specific license feature so as long as my build extracts the license feature along with the rest of the source, it's inherently consistent...

> 2. And the more general question, is there any value in hard coding
> the number even for include and plugin declarations?  I.e., does
> anyone hard code the version in of their feature.xml's plugin and
> include declarations rather than use 0.0.0?  If so, what's the value
> of a hard code number in that context, given it's more work to
> maintain it properly?

I don't think I've ever seen anything other than 0.0.0, but one possibility is a case where you don't actually want to include the "greatest" available version of something. For example if there were multiple versions of a third party feature available at build time but you wanted to explicitly include the older one (maybe platform 3.8 versus 4.2 for example). I agree this would be more work to maintain.

I see.  That's a corner case that's possible.  I imagine most avoid this by controlling carefully what's available at build time...

John

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev