Always add a version if exporting a package

[laeubi]

Currently if one exports a package

1. Using a Quickfix
2. Using the Manifest editor

PDE adds the export without a version. Unversioned packages have the drawback that one can not reliable reference them with a proper import range (what recently was added to PDE: #1007 and enhanced with #1212).

I therefore would suggest that PDE exports packages by default with version 1.0.0 (what is also the default version for Bundles created by PDE). In the rare cases where the user actively choose to not using a version, it can then be edited manually.

[merks]

Versioned packages are a good thing. That being said, does PDE, or anything else, help maintain an up-to-date version as APIs in that package change? At least for bundle versions, there are the API tools. In the end, a versioned package is only as useful as the accuracy of the version...

[laeubi]

Sadly API-Tools currently does not, but if we start more using packages (what already is done!) it might be good to enhance. Beside that Tycho offers tycho-baseline:verify mojo that supports OSGi semantics for package (and bundle) versions, e.g. m2e is using it.

Beside that, no version is as bad as a default version that never increments, so it is not really making the situation worse to use one.

[merks]

Beside that, no version is as bad as a default version that never increments, so it is not really making the situation worse to use one.

One cannot specify a version constraint on a unversioned package can one? It seems to me that an arbitrary version on a package that's not properly maintained will create a false illusion (for the consumer) that a unversioned package does not create. So I hope not to see this show up in Platform projects (but I bet it will) unless something is done to properly maintain the versions.

None of this is arguing that we should not do this is PDE, it's a word of caution to those who version their packages that they are obligated to maintain those version properly. Also, perhaps as those who encourage properly maintained version, we should consider how best to ensure that both are supported by our tools.

[laeubi]

One cannot specify a version constraint on a unversioned package can one?

Correct.

It seems to me that an arbitrary version on a package that's not properly maintained will create a false illusion

Without an version it can't be maintained at all :-)

So I hope not to see this show up in Platform projects (but I bet it will) unless something is done to properly maintain the versions.

Currently we have a wild mixture of things, at least in Equinox we try to manually maintain the versioned exports, anyways even if there are problems they can be fixed, so there is always two sides, the importers that need to maintain proper import ranges and the exporters that need to follow the semantic versioning.

I just see no other way out than starting with something simple e.g. let PDE suggest by default that packages should have a version.

[HannesWell]

It seems to me that an arbitrary version on a package that's not properly maintained will create a false illusion

Without an version it can't be maintained at all :-)

That's right. But on the other hand a not maintained package version is actually as good as no package version.

I just see no other way out than starting with something simple e.g. let PDE suggest by default that packages should have a version.

Starting simple is for sure valid, but I think if PDE just suggests to add versions without providing any support to properly maintain them, I see only really small to no value in changing that.

What would be really really helpful is if API-Tools would consider packages as well. If that would work, suggesting package version would be very valuable too.
Without being familiar with the details, I assume that it shouldn't be that hard, because the same rules that apply for the bundle version also apply for the package version. So it would be more or less additional versions to understand and smaller units to check. Respectively if API-tools detects that a change requires a new minor or major version it has to suggest the same change for the version of the containing package too, not only for the bundle version.

[laeubi]

That's right. But on the other hand a not maintained package version is actually as good as no package version.

It is not, if there is no export, then importers can't use a version at all (managed or not does not matter), so if one introduce a version later on, all consumers have to adapt ...

Starting simple is for sure valid, but I think if PDE just suggests to add versions without providing any support to properly maintain them, I see only really small to no value in changing that.

To be honest I won't recommend anyone to use API tools anyways, as mentioned for those who really care about API there are better tools like the tycho/bnd baseline that really checks for semantic versioning.

In any case please keep in mind this important part of the request:

in the rare cases where the user actively choose to not using a version, it can then be edited manually.

I have not seen any recent package export additions in platform, but even if one feels uncomfortable with that it can be changed to not using a version.

Respectively if API-tools detects that a change requires a new minor or major version it has to suggest the same change for the version of the containing package too, not only for the bundle version.

Package and bundle versions are not related and that's the biggest strength, so suggesting to change the package version the same way as the bundle version would actually be very bad.