John,
Comments below.
On 17/08/2012 3:52 PM, John Arthorne wrote:
Ed Merks <[email protected]> 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
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
