I also prefer 1.0.0 but I am fine with 2.0.0 too. The bundle version is not so important though. The really crucial part is to get the package version of the api packages right.
For now I propose to use the same version as the bundle version but then we must manage it by semantic versioning rules. Especially the package version should never have a bugfix version. So it would be 1.0 or 2.0. Christian Am Sa., 9. Feb. 2019 um 07:49 Uhr schrieb Carsten Ziegeler < [email protected]>: > > +1 to what David said > > In addition, I can't really follow the reasoning here. We're talking > about different namespaces (different packages) and that means it is not > the same API. It might have the same interfaces, methods etc. but still > it's different. So a 1.0.8 release of the Apache Felix HC API can't be > used as a replacement for a 1.0.6 release of the Apache Sling HC API. > > However, that proposed versioning scheme suggests this. > > I somehow can follow the reasoning that people who have no clue what > they are doing, get confused whether version 1.0.0 of an Apache Felix HC > API is newer or older than version 1.0.6 of an Apache Sling HC API. > > I think we either use 1.0.0 as the first release version or 2.0.0 - > everything doesn't really make sense. I would prefer 1.0.0 but the other > option is fine as well. > > > Carsten > > > 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 > >> > >> > >> > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
