Hi Ray,
so I did mention the "2.x.x " approach in the initial ticket and it
hasn't change since then [1]. But I know it's hard to always keep track
of all JIRA comments.
but I feel this is not a great approach to take.
So to me it really boils down to not counting down when moving forward
for people upgrading the health checks - it would feel awkward if you
had 1.0.2 and then you use 1.0.0 again (especially because there are no
changes to the API pending, that version might well be around for a year
or two). Also for the people not knowing the history of the move and
just looking at maven GAVs, it would always look like "sling hc api
1.0.2 is probably newer than felix hc api 1.0.0" - with the version
2.0.0 people purely looking at the GAV will have a clear direction (e.g.
if they have two projects with HCs, one upgraded already and the other
not yet)
Another example is the OSGi compendium that also did not go back down to
a 1.0.0 version after the artifact id change to "osgi.cmpn" [2]
-Georg
[1]
"Removed deprecated methods like HealthCheckExecutor.execute(String...
tags) and using version 2.x.x for both maven and OSGi packages as
starting point in Felix now"
from
https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281
[2]
https://search.maven.org/search?q=g:org.osgi%20AND%20a:org.osgi.compendium&core=gav
https://search.maven.org/search?q=g:org.osgi%20AND%20a:osgi.cmpn&core=gav
On 2019-01-31 22:15, Raymond Auge wrote:
I think the version 2.0.0 is weird when this is a new project in the
org.apache.felix namespace.
It doesn't matter that it previously had a higher version in some other
namespace.
I really recommend just making this either a 0.1.0 or 1.0.0 release. I
will
not vito the release or anything if it comes down to it but I feel this
is
not a great approach to take.
Sincerely,
- Ray
