Ed Merks <ed.merks@xxxxxxxxx> wrote on 08/17/2012
> 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
> 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. If an EPL v2.0 came out, we couldn't have projects automatically
picking it up. 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. 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.
> 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
> 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.