+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]
