Semantic versioning (was: NP-Completeness...)

[mark.reinhold at oracle.com]

2011/12/23 6:33 -0800, jesse.glick at oracle.com:
> On 12/23/2011 03:35 AM, Peter Kriens wrote:
>> With an API you have a consumer of an API and a provider of that API [...]
>> few people get the implications of APIs based programming and semantic versioning.
> 
> I guess you are referring to semver [1]. I agree that, while well-intentioned,
> that system does not adequately deal with modules which expose both a
> widely-used API and an SPI with a few implementations, or (more generally)
> multiple categories of interface intended for different clients with varying
> tolerance for incompatibility. If all these interfaces are presented
> indiscriminately as the "exports" of a versioned module, you get into a
> catch-22 when trying to introduce an incompatible SPI change while keeping the
> API fully compatible (or, generally, changing only those interfaces with a few
> well-known clients): you must mark the module version incompatible, to ensure
> that SPI implementors are updated to match the changes; but if you do so then
> the universe of API users will be gratuitously shut out of what would otherwise
> be a simple upgrade.

This is an important use case -- we hadn't considered it before, so
thanks for bringing it up.

> An unsatisfactory resolution is to version all SPI changes like compatible API
> changes, and just hope for the best. This seems to have been the policy of Java
> SE, with the result that the occasional implementor of DOM or JDBC interfaces
> (proxies, unit test mocks, ...) routinely becomes uncompilable with a new JDK
> (*). Such a policy becomes intolerable when pieces of the platform are
> downloaded according to version constraints.

Agreed.

> Another resolution is to separate the SPI into its own package structure (as is
> common anyway) and version individual packages, as might be done in OSGi
> bundles. This is impossible in the current design of Jigsaw, of course, or
> generally in any module system aspiring to have a 1-1 mapping between module
> versions (and dependencies) and native package versions (resp. dependencies).

Another possibility for Jigsaw is to remove the constraint that a
non-default module view inherits the version of its containing module.
If a view could declare its own version then an SPI view could evolve
independently from the API view of the same module.  This change would,
however, complicate the module-to-native-package mapping even further.

I'll take a close look at your proposed new NetBeans versioning policy
after the holidays.

- Mark