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

[Ed Merks <ed.merks@xxxxxxxxx>]

Hi,

Eike and I have been working on a tool for helping manage plugin and feature versions (as well as other types of consistency checks).  API Tooling is very useful for keeping track of when you should increment a plugin's major or minor version, but nothing currently helps you manage your micro versions.  It's very easy to forget to increment the minor version after making a content change (body of some method, for example) and it's hard to remember whether you've already incremented the micro version for the current stream.  Our idea is to create a base line, i.e., to keep track of all bundles and features as well as their versions at the start of a stream along with digests so we know when the contents of bundles and features change.  A content change requires an increment to the micro version and we create markers (with quick fixes) to flag these.  Feature inclusions are taken into account, so if you change the version of a bundle, you're prompted to appropriately increment the features that directly or indirectly include that bundle.   We can detect redundancies in the includes, i.e., include a plugin that's already included by a feature as well as breaking changes, e.g., removing a plugin. The new "version builder" tool is mostly working now and is part of CDO.  We'll make it's feature available via CDO's p2 update site...

As part of some final touch-ups, we were looking at license feature support.    E.g., EMF's org.eclipse.emf feature specifies its license feature like this:

<feature
      id="org.eclipse.emf"
      label="%featureName"
      version="2.8.0.qualifier"
      provider-name="%providerName"
      image="eclipse_update_120.jpg"
      license-feature="org.eclipse.emf.license"
      license-feature-version="2.7.0.qualifier">

Note in particular that we "hard code" the version of the license feature.  We noticed that specifying license-feature-version="0.0.0" also works, much like it does for includes and plugins.  By works, I mean exporting the feature resolves the license correctly and produces the correct resulting binaries that contain the copied license files.  We're not sure if Buckminster works the same way; we hope so. (Maybe Thomas will comment.)  Note that if you specify an incorrect version, e.g., license-feature-version="200.7.0.qualifier" PDE doesn't produce errors, but the exporter fails and complains that the license feature doesn't resolve. Our version tool could produce an error for this at development time.  In any case, it seems that 0.0.0 ought to work in general, and that this would be an improvement over hard coding the number...

So, now for the questions:

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? 
   
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?
   

Regards,
Ed