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

[Jaroslav Tulach]

>## 23. 12. 2011 22:16:51 ##<
> 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

Yes, having API and SPI inside of a single module tights them together. It 
takes a bit of self-dedication to keep backward compatibility of the SPI 
(implemented by few guys) on par with compatibility of API used by millions. 
However it is not impossible. In the NetBeans modules where we properly 
separated the types in API from the types in SPI, we have not usually had 
problems keeping compatibility for both.

> > 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.

Jesse is right that sometimes (when there is not enough will to design both 
API and SPI for evolution and separate them), we get into problems and then 
proper versioning (e.g. marking the new version as incompatible due to change 
in SPI only) is more hurting regular users (of the API) than helping them.

Btw. JDK8 extender methods may mitigate this problem a lot. With them one can 
extend an interface used both as API and SPI with new methods and provide good 
enough default implementations so even the old implementation of the SPI can 
link and execute with new API...

> This is an important use case -- we hadn't considered it before, so
> thanks for bringing it up.
>
> 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.

What about defining new SPI view in case of an incompatible change in the SPI?

If it was possible to keep the old view around while introducing the new one, 
it would be a smooth change. 

Removing old View1 and creating new View2 may be a complication, but my 
feeling is that if (in terms of semantic versioning[1]), it is clearly stated 
that a view can only be removed in case a micro version is incremented[2], 
there still may be a way avoid the NP-completeness of the dependency 
resolution algorithm.

-jt

[1] http://semver.org/
[2] That is how I understand Jesse's proposal for change of NetBeans 
versioning http://wiki.netbeans.org/NbmPackageStability