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
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
