Fully agree with David. Regards JB
On 08/02/2019 16:34, David Bosschaert wrote: > 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 >> >> >> > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
