You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Georg Henzler <fe...@ghenzler.de> on 2019/01/28 08:34:48 UTC

[VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Hi all,

We solved 11 issues in this release:
https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
(@PMC: Could you please create the versions for this and next release in 
JIRA for the 5 modules?)

Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-1279/

You can use this UNIX script to download the release and verify the 
signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1279 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.

-Georg

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Georg Henzler <fe...@ghenzler.de>.
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
>

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Raymond Auge <ra...@liferay.com>.
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

On Thu, Jan 31, 2019 at 12:04 PM Christian Schneider <
chris@die-schneider.net> wrote:

> Honestly I should have looked into the code a lot earlier but did not find
> the time to do so.
> I did not expect that you would propose a major version. So this put me
> into quite a hurry to review the code now :-(
>
> I now went through most of it and I agree that the API looks quite good the
> way it is. So I still would have preferred a 0.1.0 release first but I can
> agree with a major release. The crucial part is to get the API right and I
> think this is the case.
>
> So +1 (non binding)
> Christian
>
> Am Do., 31. Jan. 2019 um 17:48 Uhr schrieb Georg Henzler <
> felix@ghenzler.de
> >:
>
> > I think testing can be done easily with the current SNAPSHOT (or the
> > artifacts from the staging repository if it needed to be a non-SNAPSHOT
> > dependency). Also I have done pretty intensive testing during the last
> > month (with both Felix HCs and "legacy checks" that are currently
> > implemented against Sling HC API, see [1]).
> >
> > The worst that can happen is that we find a bug in the core, that we can
> > fix with just releasing the core. I don't think test results would be
> > able to change the API, especially since it has been around for so long.
> >
> > -Georg
> >
> > [1] "The Felix HC Executor already takes Sling HCs into account"
> >
> >
> https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281
> >
> >
> > On 2019-01-31 17:37, Christian Schneider wrote:
> > > How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> > > It would give people time to test the new project and still allow us to
> > > do
> > > incompatible changes.
> > >
> > > A release of 2.0.0 right now will fixate the API. If we then do a
> > > (incompatible) change we have to create a 3.0.0 version which will
> > > confuse
> > > users that switched early.
> > >
> > > I also rather propose to name the first major release 1.0.0 but this is
> > > not
> > > really important.
> > >
> > > Christian
> > >
> > > Am Do., 31. Jan. 2019 um 17:18 Uhr schrieb Georg Henzler
> > > <felix@ghenzler.de
> > >> :
> > >
> > >> Hi Christian,
> > >>
> > >> I think the API [1] is proven and in use since 2013 (I would guess >
> > >> 2000 checks to exist out in the wild in code bases of various
> > >> projects).
> > >> The Felix API was carefully adjusted with your feedback (e.g. the
> > >> removal of state DEBUG, FELIX-6016) to make the migration path really
> > >> easy for 99% of the checks that exist.
> > >>
> > >> In the migration guide in Sling that I will write I don't think I can
> > >> ask people to change from stable version Sling HC API 1.0.2 to a Felix
> > >> API "preview version" 0.1.0. Also, maintaining Sling HCs and Felix HCs
> > >> in parallel for some time is the worst of all options IMHO.
> > >>
> > >> So this really leaves us to push forward with Felix HC API 2.0.0 - if
> > >> we
> > >> find valid reasons to make changes we'll just bump versions according
> > >> semantic versioning.
> > >>
> > >> -Georg
> > >>
> > >> [1] https://github.com/apache/sling-org-apache-sling-hc-api
> > >>
> > >>
> > >> On 2019-01-31 16:30, Christian Schneider wrote:
> > >> > I think we should not yet release a stable version. Instead I
> propose
> > >> > to
> > >> > release a 0.1.0.
> > >> > WDYT?
> > >> >
> > >> > Christian
> > >> >
> > >> >
> > >> > Am Mo., 28. Jan. 2019 um 09:44 Uhr schrieb Georg Henzler
> > >> > <felix@ghenzler.de
> > >> >> :
> > >> >
> > >> >> Hi all,
> > >> >>
> > >> >> We solved 11 issues in this release:
> > >> >>
> > >> >>
> > >>
> >
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> > >> >> (@PMC: Could you please create the versions for this and next
> release
> > >> >> in
> > >> >> JIRA for the 5 modules?)
> > >> >>
> > >> >> Staging repository:
> > >> >>
> > https://repository.apache.org/content/repositories/orgapachefelix-1279/
> > >> >>
> > >> >> You can use this UNIX script to download the release and verify the
> > >> >> signatures:
> > >> >>
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> > >> >>
> > >> >> Usage:
> > >> >> sh check_staged_release.sh 1279 /tmp/felix-staging
> > >> >>
> > >> >> Please vote to approve this release:
> > >> >>
> > >> >> [ ] +1 Approve the release
> > >> >> [ ] -1 Veto the release (please provide specific comments)
> > >> >>
> > >> >> This vote will be open for 72 hours.
> > >> >>
> > >> >> -Georg
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >>
> > >
> > >
> > > --
> >
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Christian Schneider <ch...@die-schneider.net>.
Honestly I should have looked into the code a lot earlier but did not find
the time to do so.
I did not expect that you would propose a major version. So this put me
into quite a hurry to review the code now :-(

I now went through most of it and I agree that the API looks quite good the
way it is. So I still would have preferred a 0.1.0 release first but I can
agree with a major release. The crucial part is to get the API right and I
think this is the case.

So +1 (non binding)
Christian

Am Do., 31. Jan. 2019 um 17:48 Uhr schrieb Georg Henzler <felix@ghenzler.de
>:

> I think testing can be done easily with the current SNAPSHOT (or the
> artifacts from the staging repository if it needed to be a non-SNAPSHOT
> dependency). Also I have done pretty intensive testing during the last
> month (with both Felix HCs and "legacy checks" that are currently
> implemented against Sling HC API, see [1]).
>
> The worst that can happen is that we find a bug in the core, that we can
> fix with just releasing the core. I don't think test results would be
> able to change the API, especially since it has been around for so long.
>
> -Georg
>
> [1] "The Felix HC Executor already takes Sling HCs into account"
>
> https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281
>
>
> On 2019-01-31 17:37, Christian Schneider wrote:
> > How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> > It would give people time to test the new project and still allow us to
> > do
> > incompatible changes.
> >
> > A release of 2.0.0 right now will fixate the API. If we then do a
> > (incompatible) change we have to create a 3.0.0 version which will
> > confuse
> > users that switched early.
> >
> > I also rather propose to name the first major release 1.0.0 but this is
> > not
> > really important.
> >
> > Christian
> >
> > Am Do., 31. Jan. 2019 um 17:18 Uhr schrieb Georg Henzler
> > <felix@ghenzler.de
> >> :
> >
> >> Hi Christian,
> >>
> >> I think the API [1] is proven and in use since 2013 (I would guess >
> >> 2000 checks to exist out in the wild in code bases of various
> >> projects).
> >> The Felix API was carefully adjusted with your feedback (e.g. the
> >> removal of state DEBUG, FELIX-6016) to make the migration path really
> >> easy for 99% of the checks that exist.
> >>
> >> In the migration guide in Sling that I will write I don't think I can
> >> ask people to change from stable version Sling HC API 1.0.2 to a Felix
> >> API "preview version" 0.1.0. Also, maintaining Sling HCs and Felix HCs
> >> in parallel for some time is the worst of all options IMHO.
> >>
> >> So this really leaves us to push forward with Felix HC API 2.0.0 - if
> >> we
> >> find valid reasons to make changes we'll just bump versions according
> >> semantic versioning.
> >>
> >> -Georg
> >>
> >> [1] https://github.com/apache/sling-org-apache-sling-hc-api
> >>
> >>
> >> On 2019-01-31 16:30, Christian Schneider wrote:
> >> > I think we should not yet release a stable version. Instead I propose
> >> > to
> >> > release a 0.1.0.
> >> > WDYT?
> >> >
> >> > Christian
> >> >
> >> >
> >> > Am Mo., 28. Jan. 2019 um 09:44 Uhr schrieb Georg Henzler
> >> > <felix@ghenzler.de
> >> >> :
> >> >
> >> >> Hi all,
> >> >>
> >> >> We solved 11 issues in this release:
> >> >>
> >> >>
> >>
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> >> >> (@PMC: Could you please create the versions for this and next release
> >> >> in
> >> >> JIRA for the 5 modules?)
> >> >>
> >> >> Staging repository:
> >> >>
> https://repository.apache.org/content/repositories/orgapachefelix-1279/
> >> >>
> >> >> You can use this UNIX script to download the release and verify the
> >> >> signatures:
> >> >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> >> >>
> >> >> Usage:
> >> >> sh check_staged_release.sh 1279 /tmp/felix-staging
> >> >>
> >> >> Please vote to approve this release:
> >> >>
> >> >> [ ] +1 Approve the release
> >> >> [ ] -1 Veto the release (please provide specific comments)
> >> >>
> >> >> This vote will be open for 72 hours.
> >> >>
> >> >> -Georg
> >> >>
> >> >
> >> >
> >> > --
> >>
> >
> >
> > --
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Georg Henzler <fe...@ghenzler.de>.
I think testing can be done easily with the current SNAPSHOT (or the 
artifacts from the staging repository if it needed to be a non-SNAPSHOT 
dependency). Also I have done pretty intensive testing during the last 
month (with both Felix HCs and "legacy checks" that are currently 
implemented against Sling HC API, see [1]).

The worst that can happen is that we find a bug in the core, that we can 
fix with just releasing the core. I don't think test results would be 
able to change the API, especially since it has been around for so long.

-Georg

[1] "The Felix HC Executor already takes Sling HCs into account"
https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281


On 2019-01-31 17:37, Christian Schneider wrote:
> How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> It would give people time to test the new project and still allow us to 
> do
> incompatible changes.
> 
> A release of 2.0.0 right now will fixate the API. If we then do a
> (incompatible) change we have to create a 3.0.0 version which will 
> confuse
> users that switched early.
> 
> I also rather propose to name the first major release 1.0.0 but this is 
> not
> really important.
> 
> Christian
> 
> Am Do., 31. Jan. 2019 um 17:18 Uhr schrieb Georg Henzler 
> <felix@ghenzler.de
>> :
> 
>> Hi Christian,
>> 
>> I think the API [1] is proven and in use since 2013 (I would guess >
>> 2000 checks to exist out in the wild in code bases of various 
>> projects).
>> The Felix API was carefully adjusted with your feedback (e.g. the
>> removal of state DEBUG, FELIX-6016) to make the migration path really
>> easy for 99% of the checks that exist.
>> 
>> In the migration guide in Sling that I will write I don't think I can
>> ask people to change from stable version Sling HC API 1.0.2 to a Felix
>> API "preview version" 0.1.0. Also, maintaining Sling HCs and Felix HCs
>> in parallel for some time is the worst of all options IMHO.
>> 
>> So this really leaves us to push forward with Felix HC API 2.0.0 - if 
>> we
>> find valid reasons to make changes we'll just bump versions according
>> semantic versioning.
>> 
>> -Georg
>> 
>> [1] https://github.com/apache/sling-org-apache-sling-hc-api
>> 
>> 
>> On 2019-01-31 16:30, Christian Schneider wrote:
>> > I think we should not yet release a stable version. Instead I propose
>> > to
>> > release a 0.1.0.
>> > WDYT?
>> >
>> > Christian
>> >
>> >
>> > Am Mo., 28. Jan. 2019 um 09:44 Uhr schrieb Georg Henzler
>> > <felix@ghenzler.de
>> >> :
>> >
>> >> Hi all,
>> >>
>> >> We solved 11 issues in this release:
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
>> >> (@PMC: Could you please create the versions for this and next release
>> >> in
>> >> JIRA for the 5 modules?)
>> >>
>> >> Staging repository:
>> >> https://repository.apache.org/content/repositories/orgapachefelix-1279/
>> >>
>> >> You can use this UNIX script to download the release and verify the
>> >> signatures:
>> >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> >>
>> >> Usage:
>> >> sh check_staged_release.sh 1279 /tmp/felix-staging
>> >>
>> >> Please vote to approve this release:
>> >>
>> >> [ ] +1 Approve the release
>> >> [ ] -1 Veto the release (please provide specific comments)
>> >>
>> >> This vote will be open for 72 hours.
>> >>
>> >> -Georg
>> >>
>> >
>> >
>> > --
>> 
> 
> 
> --

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Christian Schneider <ch...@die-schneider.net>.
With the 0.1.0 release we now have the chance to look into the API without
too much hurry.
So lets check if we would like to have bigger changes but we should not
hold off a stable release for too long.

I think aiming for a stable release in 1-2 weeks should be realistic.

About the release version I do not care too much. For me the main thing to
get right is the package version of the api
as this is what must be semantically versioned.

After writing that I thought it is better to actually check in the 0.1.0
release .. The package version stayed at 2.0.0 .. will have to revert my
vote.

Christian


Am Fr., 1. Feb. 2019 um 14:40 Uhr schrieb Andrei Dulvac <du...@apache.org>:

> Hi Georg.
>
> I don't want to get into a flaming debate about versioning. I've seen on
> the internet what happens.
>
> > 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
>
> It makes no sense to me, sorry. The namespace is different, it's a
> different lib. The migration path would not be affected at all by this.
> I've seen multiple libraries migrate and reset the version space, which
> makes a lot of sense. (To me, actually having the same version as the sling
> one would be confusing if I needed to migrate, but that's my own view. The
> only libs I've seen that do that are libs with mocks)
>
> > Also the Sling API has been stable for long (Bertrand has done a great
> job
> initially designing it), why would it be all the sudden not good  anymore?
>
> It's at 2.0.0, so well... 1.0.0 wasn't perfect :). But joke aside... I
> expect the need to change the API. What's the purpose of moving the HCs to
> Felix? Broadening the scope, right? This comes with different needs than
> before.
>
> As Ray said, it's weird. Someone might be tempted to release versions in
> sync of the one in sling and the one in felix and that would be a big no-no
> for me.
>
> - Andrei
>
> On Fri, Feb 1, 2019 at 2:07 PM Georg Henzler <fe...@ghenzler.de> wrote:
>
> >
> > I'm taking the hat of the many developers out there in the world that
> > use the API (the ones we cannot talk to and that do not read this
> > mailing list) - 2.0.0 it is to not confuse them. See my response from
> > this morning [1]
> >
> > Also the Sling API has been stable for long (Bertrand has done a great
> > job initially designing it), why would it be all the sudden not good
> > anymore?
> >
> > -Georg
> >
> > [1] https://www.mail-archive.com/dev@felix.apache.org/msg47690.html
> >
> > On 2019-02-01 14:00, Andrei Dulvac wrote:
> > > Hi,
> > >
> > > (Unfortunately I haven't had a chance to look over it properly)
> > >
> > > I'd just like to say I agree with Christian and Ray - a 2.0.0 initial
> > > release is not only weird, but confusing. Why?
> > > I support doing 0.X.0 releases until the api is proven to be stable and
> > > then release *1.0.0*. Why 2.0.0?
> > >
> > > - Andrei
> > >
> > >
> > >
> > > On Fri, Feb 1, 2019 at 1:53 PM Georg Henzler <fe...@ghenzler.de>
> wrote:
> > >
> > >> Hi Bertrand,
> > >>
> > >> > Testing that on snapshots is not optimal IMO as those are
> potentially
> > >> > moving targets.
> > >>
> > >> Let's do it like this then: I'll push a release 0.1.0 today (with
> > >> another short [VOTE] today that I would ask you to quickly vote +1
> > >> for)
> > >> and I'll leave this vote and [1] open until Christian and you had the
> > >> chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.
> > >>
> > >> End of next week we can then close this vote if there is no good
> > >> reason
> > >> to cancel it.
> > >>
> > >> -Georg
> > >>
> > >> [1]
> > >>
> https://repository.apache.org/content/repositories/orgapachefelix-1279/
> > >>
> > >> On 2019-02-01 12:59, Bertrand Delacretaz wrote:
> > >> > On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
> > >> > <ch...@die-schneider.net> wrote:
> > >> >> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> > >> >> It would give people time to test the new project and still allow
> us
> > >> >> to do
> > >> >> incompatible changes....
> > >> >
> > >> > I'm also strongly in favor of that, especially as these modules
> > >> > migrated from Sling and people will expect backwards compatibility.
> > >> >
> > >> > Testing that on snapshots is not optimal IMO as those are
> potentially
> > >> > moving targets.
> > >> >
> > >> > Releases are cheap - making another 1.0.0 or 2.0.0 release soon
> > >> > shouldn't be a problem.
> > >> >
> > >> > I'm -0 on releasing these modules as 2.0.0.
> > >> >
> > >> > -Bertrand
> > >>
> >
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Andrei Dulvac <du...@apache.org>.
Hi Georg.

I don't want to get into a flaming debate about versioning. I've seen on
the internet what happens.

> 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

It makes no sense to me, sorry. The namespace is different, it's a
different lib. The migration path would not be affected at all by this.
I've seen multiple libraries migrate and reset the version space, which
makes a lot of sense. (To me, actually having the same version as the sling
one would be confusing if I needed to migrate, but that's my own view. The
only libs I've seen that do that are libs with mocks)

> Also the Sling API has been stable for long (Bertrand has done a great job
initially designing it), why would it be all the sudden not good  anymore?

It's at 2.0.0, so well... 1.0.0 wasn't perfect :). But joke aside... I
expect the need to change the API. What's the purpose of moving the HCs to
Felix? Broadening the scope, right? This comes with different needs than
before.

As Ray said, it's weird. Someone might be tempted to release versions in
sync of the one in sling and the one in felix and that would be a big no-no
for me.

- Andrei

On Fri, Feb 1, 2019 at 2:07 PM Georg Henzler <fe...@ghenzler.de> wrote:

>
> I'm taking the hat of the many developers out there in the world that
> use the API (the ones we cannot talk to and that do not read this
> mailing list) - 2.0.0 it is to not confuse them. See my response from
> this morning [1]
>
> Also the Sling API has been stable for long (Bertrand has done a great
> job initially designing it), why would it be all the sudden not good
> anymore?
>
> -Georg
>
> [1] https://www.mail-archive.com/dev@felix.apache.org/msg47690.html
>
> On 2019-02-01 14:00, Andrei Dulvac wrote:
> > Hi,
> >
> > (Unfortunately I haven't had a chance to look over it properly)
> >
> > I'd just like to say I agree with Christian and Ray - a 2.0.0 initial
> > release is not only weird, but confusing. Why?
> > I support doing 0.X.0 releases until the api is proven to be stable and
> > then release *1.0.0*. Why 2.0.0?
> >
> > - Andrei
> >
> >
> >
> > On Fri, Feb 1, 2019 at 1:53 PM Georg Henzler <fe...@ghenzler.de> wrote:
> >
> >> Hi Bertrand,
> >>
> >> > Testing that on snapshots is not optimal IMO as those are potentially
> >> > moving targets.
> >>
> >> Let's do it like this then: I'll push a release 0.1.0 today (with
> >> another short [VOTE] today that I would ask you to quickly vote +1
> >> for)
> >> and I'll leave this vote and [1] open until Christian and you had the
> >> chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.
> >>
> >> End of next week we can then close this vote if there is no good
> >> reason
> >> to cancel it.
> >>
> >> -Georg
> >>
> >> [1]
> >> https://repository.apache.org/content/repositories/orgapachefelix-1279/
> >>
> >> On 2019-02-01 12:59, Bertrand Delacretaz wrote:
> >> > On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
> >> > <ch...@die-schneider.net> wrote:
> >> >> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> >> >> It would give people time to test the new project and still allow us
> >> >> to do
> >> >> incompatible changes....
> >> >
> >> > I'm also strongly in favor of that, especially as these modules
> >> > migrated from Sling and people will expect backwards compatibility.
> >> >
> >> > Testing that on snapshots is not optimal IMO as those are potentially
> >> > moving targets.
> >> >
> >> > Releases are cheap - making another 1.0.0 or 2.0.0 release soon
> >> > shouldn't be a problem.
> >> >
> >> > I'm -0 on releasing these modules as 2.0.0.
> >> >
> >> > -Bertrand
> >>
>

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Georg Henzler <fe...@ghenzler.de>.
I'm taking the hat of the many developers out there in the world that 
use the API (the ones we cannot talk to and that do not read this 
mailing list) - 2.0.0 it is to not confuse them. See my response from 
this morning [1]

Also the Sling API has been stable for long (Bertrand has done a great 
job initially designing it), why would it be all the sudden not good 
anymore?

-Georg

[1] https://www.mail-archive.com/dev@felix.apache.org/msg47690.html

On 2019-02-01 14:00, Andrei Dulvac wrote:
> Hi,
> 
> (Unfortunately I haven't had a chance to look over it properly)
> 
> I'd just like to say I agree with Christian and Ray - a 2.0.0 initial
> release is not only weird, but confusing. Why?
> I support doing 0.X.0 releases until the api is proven to be stable and
> then release *1.0.0*. Why 2.0.0?
> 
> - Andrei
> 
> 
> 
> On Fri, Feb 1, 2019 at 1:53 PM Georg Henzler <fe...@ghenzler.de> wrote:
> 
>> Hi Bertrand,
>> 
>> > Testing that on snapshots is not optimal IMO as those are potentially
>> > moving targets.
>> 
>> Let's do it like this then: I'll push a release 0.1.0 today (with
>> another short [VOTE] today that I would ask you to quickly vote +1 
>> for)
>> and I'll leave this vote and [1] open until Christian and you had the
>> chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.
>> 
>> End of next week we can then close this vote if there is no good 
>> reason
>> to cancel it.
>> 
>> -Georg
>> 
>> [1]
>> https://repository.apache.org/content/repositories/orgapachefelix-1279/
>> 
>> On 2019-02-01 12:59, Bertrand Delacretaz wrote:
>> > On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
>> > <ch...@die-schneider.net> wrote:
>> >> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
>> >> It would give people time to test the new project and still allow us
>> >> to do
>> >> incompatible changes....
>> >
>> > I'm also strongly in favor of that, especially as these modules
>> > migrated from Sling and people will expect backwards compatibility.
>> >
>> > Testing that on snapshots is not optimal IMO as those are potentially
>> > moving targets.
>> >
>> > Releases are cheap - making another 1.0.0 or 2.0.0 release soon
>> > shouldn't be a problem.
>> >
>> > I'm -0 on releasing these modules as 2.0.0.
>> >
>> > -Bertrand
>>

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Andrei Dulvac <du...@apache.org>.
Hi,

(Unfortunately I haven't had a chance to look over it properly)

I'd just like to say I agree with Christian and Ray - a 2.0.0 initial
release is not only weird, but confusing. Why?
I support doing 0.X.0 releases until the api is proven to be stable and
then release *1.0.0*. Why 2.0.0?

- Andrei



On Fri, Feb 1, 2019 at 1:53 PM Georg Henzler <fe...@ghenzler.de> wrote:

> Hi Bertrand,
>
> > Testing that on snapshots is not optimal IMO as those are potentially
> > moving targets.
>
> Let's do it like this then: I'll push a release 0.1.0 today (with
> another short [VOTE] today that I would ask you to quickly vote +1 for)
> and I'll leave this vote and [1] open until Christian and you had the
> chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.
>
> End of next week we can then close this vote if there is no good reason
> to cancel it.
>
> -Georg
>
> [1]
> https://repository.apache.org/content/repositories/orgapachefelix-1279/
>
> On 2019-02-01 12:59, Bertrand Delacretaz wrote:
> > On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
> > <ch...@die-schneider.net> wrote:
> >> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> >> It would give people time to test the new project and still allow us
> >> to do
> >> incompatible changes....
> >
> > I'm also strongly in favor of that, especially as these modules
> > migrated from Sling and people will expect backwards compatibility.
> >
> > Testing that on snapshots is not optimal IMO as those are potentially
> > moving targets.
> >
> > Releases are cheap - making another 1.0.0 or 2.0.0 release soon
> > shouldn't be a problem.
> >
> > I'm -0 on releasing these modules as 2.0.0.
> >
> > -Bertrand
>

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Georg Henzler <fe...@ghenzler.de>.
Hi Bertrand,

> Testing that on snapshots is not optimal IMO as those are potentially 
> moving targets.

Let's do it like this then: I'll push a release 0.1.0 today (with 
another short [VOTE] today that I would ask you to quickly vote +1 for) 
and I'll leave this vote and [1] open until Christian and you had the 
chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.

End of next week we can then close this vote if there is no good reason 
to cancel it.

-Georg

[1] 
https://repository.apache.org/content/repositories/orgapachefelix-1279/

On 2019-02-01 12:59, Bertrand Delacretaz wrote:
> On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
> <ch...@die-schneider.net> wrote:
>> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
>> It would give people time to test the new project and still allow us 
>> to do
>> incompatible changes....
> 
> I'm also strongly in favor of that, especially as these modules
> migrated from Sling and people will expect backwards compatibility.
> 
> Testing that on snapshots is not optimal IMO as those are potentially
> moving targets.
> 
> Releases are cheap - making another 1.0.0 or 2.0.0 release soon
> shouldn't be a problem.
> 
> I'm -0 on releasing these modules as 2.0.0.
> 
> -Bertrand

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
<ch...@die-schneider.net> wrote:
> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> It would give people time to test the new project and still allow us to do
> incompatible changes....

I'm also strongly in favor of that, especially as these modules
migrated from Sling and people will expect backwards compatibility.

Testing that on snapshots is not optimal IMO as those are potentially
moving targets.

Releases are cheap - making another 1.0.0 or 2.0.0 release soon
shouldn't be a problem.

I'm -0 on releasing these modules as 2.0.0.

-Bertrand

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Christian Schneider <ch...@die-schneider.net>.
How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
It would give people time to test the new project and still allow us to do
incompatible changes.

A release of 2.0.0 right now will fixate the API. If we then do a
(incompatible) change we have to create a 3.0.0 version which will confuse
users that switched early.

I also rather propose to name the first major release 1.0.0 but this is not
really important.

Christian

Am Do., 31. Jan. 2019 um 17:18 Uhr schrieb Georg Henzler <felix@ghenzler.de
>:

> Hi Christian,
>
> I think the API [1] is proven and in use since 2013 (I would guess >
> 2000 checks to exist out in the wild in code bases of various projects).
> The Felix API was carefully adjusted with your feedback (e.g. the
> removal of state DEBUG, FELIX-6016) to make the migration path really
> easy for 99% of the checks that exist.
>
> In the migration guide in Sling that I will write I don't think I can
> ask people to change from stable version Sling HC API 1.0.2 to a Felix
> API "preview version" 0.1.0. Also, maintaining Sling HCs and Felix HCs
> in parallel for some time is the worst of all options IMHO.
>
> So this really leaves us to push forward with Felix HC API 2.0.0 - if we
> find valid reasons to make changes we'll just bump versions according
> semantic versioning.
>
> -Georg
>
> [1] https://github.com/apache/sling-org-apache-sling-hc-api
>
>
> On 2019-01-31 16:30, Christian Schneider wrote:
> > I think we should not yet release a stable version. Instead I propose
> > to
> > release a 0.1.0.
> > WDYT?
> >
> > Christian
> >
> >
> > Am Mo., 28. Jan. 2019 um 09:44 Uhr schrieb Georg Henzler
> > <felix@ghenzler.de
> >> :
> >
> >> Hi all,
> >>
> >> We solved 11 issues in this release:
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> >> (@PMC: Could you please create the versions for this and next release
> >> in
> >> JIRA for the 5 modules?)
> >>
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachefelix-1279/
> >>
> >> You can use this UNIX script to download the release and verify the
> >> signatures:
> >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> >>
> >> Usage:
> >> sh check_staged_release.sh 1279 /tmp/felix-staging
> >>
> >> Please vote to approve this release:
> >>
> >> [ ] +1 Approve the release
> >> [ ] -1 Veto the release (please provide specific comments)
> >>
> >> This vote will be open for 72 hours.
> >>
> >> -Georg
> >>
> >
> >
> > --
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Georg Henzler <fe...@ghenzler.de>.
Hi Christian,

I think the API [1] is proven and in use since 2013 (I would guess > 
2000 checks to exist out in the wild in code bases of various projects). 
The Felix API was carefully adjusted with your feedback (e.g. the 
removal of state DEBUG, FELIX-6016) to make the migration path really 
easy for 99% of the checks that exist.

In the migration guide in Sling that I will write I don't think I can 
ask people to change from stable version Sling HC API 1.0.2 to a Felix 
API "preview version" 0.1.0. Also, maintaining Sling HCs and Felix HCs 
in parallel for some time is the worst of all options IMHO.

So this really leaves us to push forward with Felix HC API 2.0.0 - if we 
find valid reasons to make changes we'll just bump versions according 
semantic versioning.

-Georg

[1] https://github.com/apache/sling-org-apache-sling-hc-api


On 2019-01-31 16:30, Christian Schneider wrote:
> I think we should not yet release a stable version. Instead I propose 
> to
> release a 0.1.0.
> WDYT?
> 
> Christian
> 
> 
> Am Mo., 28. Jan. 2019 um 09:44 Uhr schrieb Georg Henzler 
> <felix@ghenzler.de
>> :
> 
>> Hi all,
>> 
>> We solved 11 issues in this release:
>> 
>> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
>> (@PMC: Could you please create the versions for this and next release 
>> in
>> JIRA for the 5 modules?)
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1279/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1279 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> This vote will be open for 72 hours.
>> 
>> -Georg
>> 
> 
> 
> --

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Christian Schneider <ch...@die-schneider.net>.
I think we should not yet release a stable version. Instead I propose to
release a 0.1.0.
WDYT?

Christian


Am Mo., 28. Jan. 2019 um 09:44 Uhr schrieb Georg Henzler <felix@ghenzler.de
>:

> Hi all,
>
> We solved 11 issues in this release:
>
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> (@PMC: Could you please create the versions for this and next release in
> JIRA for the 5 modules?)
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1279/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1279 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>
> -Georg
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Georg Henzler <fe...@ghenzler.de>.
+1 from myself as well

@Karl: Thanks for giving me the JIRA permissions, I added all versions 
and assigned them to the tickets.

-Georg


On 2019-01-31 13:58, Karl Pauls wrote:
> +1
> 
> Sorry it took me so long to get to it. I increased your permissions
> for JIRA - can you see if you can do the releases yourself now?
> 
> regards,
> 
> Karl
> 
> On Mon, Jan 28, 2019 at 9:44 AM Georg Henzler <fe...@ghenzler.de> 
> wrote:
>> 
>> Hi all,
>> 
>> We solved 11 issues in this release:
>> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
>> (@PMC: Could you please create the versions for this and next release 
>> in
>> JIRA for the 5 modules?)
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1279/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1279 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> This vote will be open for 72 hours.
>> 
>> -Georg

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

Posted by Karl Pauls <ka...@gmail.com>.
+1

Sorry it took me so long to get to it. I increased your permissions
for JIRA - can you see if you can do the releases yourself now?

regards,

Karl

On Mon, Jan 28, 2019 at 9:44 AM Georg Henzler <fe...@ghenzler.de> wrote:
>
> Hi all,
>
> We solved 11 issues in this release:
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> (@PMC: Could you please create the versions for this and next release in
> JIRA for the 5 modules?)
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1279/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1279 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>
> -Georg



-- 
Karl Pauls
karlpauls@gmail.com