Hi Georg, Version numbers starting with 0.x have a special meaning in that they communicate that the API is non-final. You did this release recently so that's great.
A major version of the release declares compatibility, staying within the same major means that at least consumers can expect compatibility. Switching to the next major version is effectively saying: everyone needs to change. So really it means that it's a completely different API (although it might resemble another version of the API). I would actually argue that there technically no ordering between major version numbers (technically version 4 could come after version 5) although humans like to think that there is ordering between 4 and 5 as a major version number. Because the artifacts are in a different namespace (now Felix, was Sling) you could just start with major version 1 again. However maybe people find that confusing. You could also start with version 314 or whatever number, but I guess people would slightly raise their eyebrows about that too. I guess the least surprising option would be to go with either 1.x or 2.x. If you think that 2.x is less confusing then I would have no problem with that. The one thing that I would be a little cautious about is switching from a 0.x to a API-fixed release. Normally there would be a little more time between this so that people have the time to work with it and potentially find problems with. Best regards, David On Fri, 8 Feb 2019 at 07:21, Georg Henzler <[email protected]> wrote: > Hi all, > > before starting a release vote again and starting discussing the version > number there, let's try to find an agreement before :) > > So now that we have had a test release 0.1.1 I think everybody would be > ok to move to versions >=1.0.0 I suppose. For developers implementing > against the health check API and annotations I think it is important to > quickly be able to tell apart newer from older without digging in > documentation (which often just does not happen, then developers do the > wrong thing). So for me it would be important to use a version number > higher than the following two Sling maven artifacts: > > org.apache.sling:org.apache.sling.hc.annotations:1.0.6 > org.apache.sling:org.apache.sling.hc.api:1.0.2 > > So for > org.apache.felix:org.apache.felix.healthcheck.annotation > org.apache.felix:org.apache.felix.healthcheck.api > I would suggest to use at least 1.0.8 and 1.0.4 respectively. > > For the modules core, generalchecks and webconsoleplugin it is just a > version number and it does not really matter. Also for the OSGi package > export version of the two API packages it could be anything really. > > So we have the following options: > > 1) everything 1.0.0 is not a good option (because then it's not clear > enough that Felix API/annotations are newer than Sling) > 2) everything 1.1.0 (would work for me) > 3) everything 1.5.0 (would work for me) > 4) everything 2.0.0 (what I proposed initially, still my favorite) > 5) mixed approach of using 1.0.8 and 1.0.4 for annotations/api, 1.0.0 > for everything else (where it does not matter) > > WDYT? > > -Georg > > >
