You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Andor Molnar <an...@apache.org> on 2020/01/22 10:59:36 UTC
Re: Release procedure for 3.6.0 - new ideas with maven release plugin
Hi,
We started a discussion on Slack about branching/not branching for new releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico has not created branch for 3.6.0 and I’d like to talk about the motivations.
Personally I’ve found the separate branch useful in the release process, because I didn’t have to ask people not to submit new patches on branch-3.5 due to ongoing release process. On the flipside, fixes which have come up during release validation had to be submitted for 2 branches: branch-3.5 and branch-3.5.X.
Either way I would keep our current branching strategy, but also would like to hear everybody’s opinion.
Regards,
Andor
> On 2019. Nov 11., at 22:19, Enrico Olivelli <eo...@gmail.com> wrote:
>
> Hello,
> in 3.5 we did a great work (in particular Andor and Norbert) in order to
> mavenize our repository and current we are performing releases from 3.5
> branch with Maven.
>
> For 3.6.0 I would like to try to enhance the procedure a bit and make it
> simpler, by using the Maven Release Plugin [1].
>
> I am drafting a new procedure [2], but it is still not ready,
> Once I am done with it the procedure will look like this [3] or [4]
>
> The major problem with the Maven release plugin is to update the versions
> on the C client, but I have found some trick so I am doing tests.
>
> I am just waiting for pending PRs that have been said to be nice to have on
> 3.6.0 to land to master then I am confident we are ready to cut a release
>
> Any comments and help are welcome
>
> Enrico
>
> [1] https://maven.apache.org/maven-release/maven-release-plugin/
> [2]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428
> [3] https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
> [4] https://github.com/diennea/herddb/wiki/Release-guide
Re: Release procedure for 3.6.0 - new ideas with maven release plugin
Posted by David Mollitor <da...@gmail.com>.
Might be nice to have one final maintenance release before EoL. But yes,
there are not too many branches to maintain in my opinion.
On Wed, Jan 22, 2020, 9:40 AM Andor Molnar <an...@apache.org> wrote:
> Afaik it will be EOL once we release 3.6.0.
> It will be highlighted in the release notes.
>
> Andor
>
>
>
> > On 2020. Jan 22., at 15:07, David Mollitor <da...@gmail.com> wrote:
> >
> > I think you are doing it correct.
> >
> > ZK is in a good position in that it doesn't have that many branches to
> > maintain: 3.4, 3.5, 3.6, and now 3.7.
> >
> > How long do you want to continue the 3.4 branch, or is it already EoL?
> >
> > Thanks.
> >
> > On Wed, Jan 22, 2020, 5:59 AM Andor Molnar <an...@apache.org> wrote:
> >
> >> Hi,
> >>
> >> We started a discussion on Slack about branching/not branching for new
> >> releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico has
> >> not created branch for 3.6.0 and I’d like to talk about the motivations.
> >>
> >> Personally I’ve found the separate branch useful in the release process,
> >> because I didn’t have to ask people not to submit new patches on
> branch-3.5
> >> due to ongoing release process. On the flipside, fixes which have come
> up
> >> during release validation had to be submitted for 2 branches: branch-3.5
> >> and branch-3.5.X.
> >>
> >> Either way I would keep our current branching strategy, but also would
> >> like to hear everybody’s opinion.
> >>
> >> Regards,
> >> Andor
> >>
> >>
> >>
> >>
> >>> On 2019. Nov 11., at 22:19, Enrico Olivelli <eo...@gmail.com>
> wrote:
> >>>
> >>> Hello,
> >>> in 3.5 we did a great work (in particular Andor and Norbert) in order
> to
> >>> mavenize our repository and current we are performing releases from 3.5
> >>> branch with Maven.
> >>>
> >>> For 3.6.0 I would like to try to enhance the procedure a bit and make
> it
> >>> simpler, by using the Maven Release Plugin [1].
> >>>
> >>> I am drafting a new procedure [2], but it is still not ready,
> >>> Once I am done with it the procedure will look like this [3] or [4]
> >>>
> >>> The major problem with the Maven release plugin is to update the
> versions
> >>> on the C client, but I have found some trick so I am doing tests.
> >>>
> >>> I am just waiting for pending PRs that have been said to be nice to
> have
> >> on
> >>> 3.6.0 to land to master then I am confident we are ready to cut a
> release
> >>>
> >>> Any comments and help are welcome
> >>>
> >>> Enrico
> >>>
> >>> [1] https://maven.apache.org/maven-release/maven-release-plugin/
> >>> [2]
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428
> >>> [3]
> >>
> https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
> >>> [4] https://github.com/diennea/herddb/wiki/Release-guide
> >>
> >>
>
>
Re: Release procedure for 3.6.0 - new ideas with maven release plugin
Posted by Andor Molnar <an...@apache.org>.
Afaik it will be EOL once we release 3.6.0.
It will be highlighted in the release notes.
Andor
> On 2020. Jan 22., at 15:07, David Mollitor <da...@gmail.com> wrote:
>
> I think you are doing it correct.
>
> ZK is in a good position in that it doesn't have that many branches to
> maintain: 3.4, 3.5, 3.6, and now 3.7.
>
> How long do you want to continue the 3.4 branch, or is it already EoL?
>
> Thanks.
>
> On Wed, Jan 22, 2020, 5:59 AM Andor Molnar <an...@apache.org> wrote:
>
>> Hi,
>>
>> We started a discussion on Slack about branching/not branching for new
>> releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico has
>> not created branch for 3.6.0 and I’d like to talk about the motivations.
>>
>> Personally I’ve found the separate branch useful in the release process,
>> because I didn’t have to ask people not to submit new patches on branch-3.5
>> due to ongoing release process. On the flipside, fixes which have come up
>> during release validation had to be submitted for 2 branches: branch-3.5
>> and branch-3.5.X.
>>
>> Either way I would keep our current branching strategy, but also would
>> like to hear everybody’s opinion.
>>
>> Regards,
>> Andor
>>
>>
>>
>>
>>> On 2019. Nov 11., at 22:19, Enrico Olivelli <eo...@gmail.com> wrote:
>>>
>>> Hello,
>>> in 3.5 we did a great work (in particular Andor and Norbert) in order to
>>> mavenize our repository and current we are performing releases from 3.5
>>> branch with Maven.
>>>
>>> For 3.6.0 I would like to try to enhance the procedure a bit and make it
>>> simpler, by using the Maven Release Plugin [1].
>>>
>>> I am drafting a new procedure [2], but it is still not ready,
>>> Once I am done with it the procedure will look like this [3] or [4]
>>>
>>> The major problem with the Maven release plugin is to update the versions
>>> on the C client, but I have found some trick so I am doing tests.
>>>
>>> I am just waiting for pending PRs that have been said to be nice to have
>> on
>>> 3.6.0 to land to master then I am confident we are ready to cut a release
>>>
>>> Any comments and help are welcome
>>>
>>> Enrico
>>>
>>> [1] https://maven.apache.org/maven-release/maven-release-plugin/
>>> [2]
>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428
>>> [3]
>> https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
>>> [4] https://github.com/diennea/herddb/wiki/Release-guide
>>
>>
Re: Release procedure for 3.6.0 - new ideas with maven release plugin
Posted by David Mollitor <da...@gmail.com>.
I think you are doing it correct.
ZK is in a good position in that it doesn't have that many branches to
maintain: 3.4, 3.5, 3.6, and now 3.7.
How long do you want to continue the 3.4 branch, or is it already EoL?
Thanks.
On Wed, Jan 22, 2020, 5:59 AM Andor Molnar <an...@apache.org> wrote:
> Hi,
>
> We started a discussion on Slack about branching/not branching for new
> releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico has
> not created branch for 3.6.0 and I’d like to talk about the motivations.
>
> Personally I’ve found the separate branch useful in the release process,
> because I didn’t have to ask people not to submit new patches on branch-3.5
> due to ongoing release process. On the flipside, fixes which have come up
> during release validation had to be submitted for 2 branches: branch-3.5
> and branch-3.5.X.
>
> Either way I would keep our current branching strategy, but also would
> like to hear everybody’s opinion.
>
> Regards,
> Andor
>
>
>
>
> > On 2019. Nov 11., at 22:19, Enrico Olivelli <eo...@gmail.com> wrote:
> >
> > Hello,
> > in 3.5 we did a great work (in particular Andor and Norbert) in order to
> > mavenize our repository and current we are performing releases from 3.5
> > branch with Maven.
> >
> > For 3.6.0 I would like to try to enhance the procedure a bit and make it
> > simpler, by using the Maven Release Plugin [1].
> >
> > I am drafting a new procedure [2], but it is still not ready,
> > Once I am done with it the procedure will look like this [3] or [4]
> >
> > The major problem with the Maven release plugin is to update the versions
> > on the C client, but I have found some trick so I am doing tests.
> >
> > I am just waiting for pending PRs that have been said to be nice to have
> on
> > 3.6.0 to land to master then I am confident we are ready to cut a release
> >
> > Any comments and help are welcome
> >
> > Enrico
> >
> > [1] https://maven.apache.org/maven-release/maven-release-plugin/
> > [2]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428
> > [3]
> https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
> > [4] https://github.com/diennea/herddb/wiki/Release-guide
>
>
Re: Release procedure for 3.6.0 - new ideas with maven release plugin
Posted by Enrico Olivelli <eo...@gmail.com>.
I think it is better to continue to create a specific branch for each
release.
There is no strong motivation for changing this part of the procedure.
I would say that we should clean up and drop such branches after the
completion of the release process, only the signed git tag will stay.
I will update the new procedure with this step.
I will create a branch-3.6.0 branch as usual.
Thanks to Andor for bringing up this useful discussion
Enrico
Il Gio 23 Gen 2020, 23:10 Patrick Hunt <ph...@apache.org> ha scritto:
> On Thu, Jan 23, 2020 at 2:02 AM Norbert Kalmar
> <nk...@cloudera.com.invalid>
> wrote:
>
> > I also agree that branching for a release makes the process easier.
> > Especially if we are talking about the active branch. For example, I
> > wouldn't do a branch for a new 3.4 release, as it's pretty much EOL and
> > hardly anything makes it there.
> > My opinion, if it makes sense to branch out for a release, then why not.
> A
> > branch "cost" is pretty much nothing. So probably this can be the
> decision
> > of the RM? I know committers should always be aware of the branching
> > strategy used in order to know where to commit, but I don't think this
> > should be a problem to follow. We don't have releases that often.
> > Although it is getting more and more frequent fortunately :)
> >
> > TLDR: let the RM decide for every release to branch or not? Seems this
> was
> > the case recently anyway.
> >
>
> I don't think this is a good idea. Release mechanics should be ...
> mechanical. Consistent. That way when an RM picks up the duty next time
> there is no guessing (by the rm or the folks trying to follow along) and
> the "artifacts" from the release are more consistent. Granted process can
> change over time, but hopefully less frequently than releases themselves.
> Also the window of a release is typically small, however we have had cases
> where it took a long time to get the release finalized with many rcs.
>
> Patrick
>
>
> >
> > Regards,
> > Norbert
> >
> > On Wed, Jan 22, 2020 at 5:22 PM Patrick Hunt <ph...@apache.org> wrote:
> >
> > > On Wed, Jan 22, 2020 at 2:59 AM Andor Molnar <an...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > We started a discussion on Slack about branching/not branching for
> new
> > > > releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico
> > has
> > > > not created branch for 3.6.0 and I’d like to talk about the
> > motivations.
> > > >
> > > > Personally I’ve found the separate branch useful in the release
> > process,
> > > > because I didn’t have to ask people not to submit new patches on
> > > branch-3.5
> > > > due to ongoing release process. On the flipside, fixes which have
> come
> > up
> > > > during release validation had to be submitted for 2 branches:
> > branch-3.5
> > > > and branch-3.5.X.
> > > >
> > > >
> > > We didn't used to have branches for releases and added them
> specifically
> > > for this reason - to allow commits while release in progress. Given the
> > RM
> > > can (should) make the decision whether or not to pull things into a
> > release
> > > candidate this seems fine with me (3.5 vs 3.5.x)
> > >
> > > Patrick
> > >
> > >
> > > > Either way I would keep our current branching strategy, but also
> would
> > > > like to hear everybody’s opinion.
> > > >
> > > > Regards,
> > > > Andor
> > > >
> > > >
> > > >
> > > >
> > > > > On 2019. Nov 11., at 22:19, Enrico Olivelli <eo...@gmail.com>
> > > wrote:
> > > > >
> > > > > Hello,
> > > > > in 3.5 we did a great work (in particular Andor and Norbert) in
> order
> > > to
> > > > > mavenize our repository and current we are performing releases from
> > 3.5
> > > > > branch with Maven.
> > > > >
> > > > > For 3.6.0 I would like to try to enhance the procedure a bit and
> make
> > > it
> > > > > simpler, by using the Maven Release Plugin [1].
> > > > >
> > > > > I am drafting a new procedure [2], but it is still not ready,
> > > > > Once I am done with it the procedure will look like this [3] or [4]
> > > > >
> > > > > The major problem with the Maven release plugin is to update the
> > > versions
> > > > > on the C client, but I have found some trick so I am doing tests.
> > > > >
> > > > > I am just waiting for pending PRs that have been said to be nice to
> > > have
> > > > on
> > > > > 3.6.0 to land to master then I am confident we are ready to cut a
> > > release
> > > > >
> > > > > Any comments and help are welcome
> > > > >
> > > > > Enrico
> > > > >
> > > > > [1] https://maven.apache.org/maven-release/maven-release-plugin/
> > > > > [2]
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428
> > > > > [3]
> > > >
> > https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
> > > > > [4] https://github.com/diennea/herddb/wiki/Release-guide
> > > >
> > > >
> > >
> >
>
Re: Release procedure for 3.6.0 - new ideas with maven release plugin
Posted by Patrick Hunt <ph...@apache.org>.
On Thu, Jan 23, 2020 at 2:02 AM Norbert Kalmar <nk...@cloudera.com.invalid>
wrote:
> I also agree that branching for a release makes the process easier.
> Especially if we are talking about the active branch. For example, I
> wouldn't do a branch for a new 3.4 release, as it's pretty much EOL and
> hardly anything makes it there.
> My opinion, if it makes sense to branch out for a release, then why not. A
> branch "cost" is pretty much nothing. So probably this can be the decision
> of the RM? I know committers should always be aware of the branching
> strategy used in order to know where to commit, but I don't think this
> should be a problem to follow. We don't have releases that often.
> Although it is getting more and more frequent fortunately :)
>
> TLDR: let the RM decide for every release to branch or not? Seems this was
> the case recently anyway.
>
I don't think this is a good idea. Release mechanics should be ...
mechanical. Consistent. That way when an RM picks up the duty next time
there is no guessing (by the rm or the folks trying to follow along) and
the "artifacts" from the release are more consistent. Granted process can
change over time, but hopefully less frequently than releases themselves.
Also the window of a release is typically small, however we have had cases
where it took a long time to get the release finalized with many rcs.
Patrick
>
> Regards,
> Norbert
>
> On Wed, Jan 22, 2020 at 5:22 PM Patrick Hunt <ph...@apache.org> wrote:
>
> > On Wed, Jan 22, 2020 at 2:59 AM Andor Molnar <an...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > We started a discussion on Slack about branching/not branching for new
> > > releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico
> has
> > > not created branch for 3.6.0 and I’d like to talk about the
> motivations.
> > >
> > > Personally I’ve found the separate branch useful in the release
> process,
> > > because I didn’t have to ask people not to submit new patches on
> > branch-3.5
> > > due to ongoing release process. On the flipside, fixes which have come
> up
> > > during release validation had to be submitted for 2 branches:
> branch-3.5
> > > and branch-3.5.X.
> > >
> > >
> > We didn't used to have branches for releases and added them specifically
> > for this reason - to allow commits while release in progress. Given the
> RM
> > can (should) make the decision whether or not to pull things into a
> release
> > candidate this seems fine with me (3.5 vs 3.5.x)
> >
> > Patrick
> >
> >
> > > Either way I would keep our current branching strategy, but also would
> > > like to hear everybody’s opinion.
> > >
> > > Regards,
> > > Andor
> > >
> > >
> > >
> > >
> > > > On 2019. Nov 11., at 22:19, Enrico Olivelli <eo...@gmail.com>
> > wrote:
> > > >
> > > > Hello,
> > > > in 3.5 we did a great work (in particular Andor and Norbert) in order
> > to
> > > > mavenize our repository and current we are performing releases from
> 3.5
> > > > branch with Maven.
> > > >
> > > > For 3.6.0 I would like to try to enhance the procedure a bit and make
> > it
> > > > simpler, by using the Maven Release Plugin [1].
> > > >
> > > > I am drafting a new procedure [2], but it is still not ready,
> > > > Once I am done with it the procedure will look like this [3] or [4]
> > > >
> > > > The major problem with the Maven release plugin is to update the
> > versions
> > > > on the C client, but I have found some trick so I am doing tests.
> > > >
> > > > I am just waiting for pending PRs that have been said to be nice to
> > have
> > > on
> > > > 3.6.0 to land to master then I am confident we are ready to cut a
> > release
> > > >
> > > > Any comments and help are welcome
> > > >
> > > > Enrico
> > > >
> > > > [1] https://maven.apache.org/maven-release/maven-release-plugin/
> > > > [2]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428
> > > > [3]
> > >
> https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
> > > > [4] https://github.com/diennea/herddb/wiki/Release-guide
> > >
> > >
> >
>
Re: Release procedure for 3.6.0 - new ideas with maven release plugin
Posted by Norbert Kalmar <nk...@cloudera.com.INVALID>.
I also agree that branching for a release makes the process easier.
Especially if we are talking about the active branch. For example, I
wouldn't do a branch for a new 3.4 release, as it's pretty much EOL and
hardly anything makes it there.
My opinion, if it makes sense to branch out for a release, then why not. A
branch "cost" is pretty much nothing. So probably this can be the decision
of the RM? I know committers should always be aware of the branching
strategy used in order to know where to commit, but I don't think this
should be a problem to follow. We don't have releases that often.
Although it is getting more and more frequent fortunately :)
TLDR: let the RM decide for every release to branch or not? Seems this was
the case recently anyway.
Regards,
Norbert
On Wed, Jan 22, 2020 at 5:22 PM Patrick Hunt <ph...@apache.org> wrote:
> On Wed, Jan 22, 2020 at 2:59 AM Andor Molnar <an...@apache.org> wrote:
>
> > Hi,
> >
> > We started a discussion on Slack about branching/not branching for new
> > releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico has
> > not created branch for 3.6.0 and I’d like to talk about the motivations.
> >
> > Personally I’ve found the separate branch useful in the release process,
> > because I didn’t have to ask people not to submit new patches on
> branch-3.5
> > due to ongoing release process. On the flipside, fixes which have come up
> > during release validation had to be submitted for 2 branches: branch-3.5
> > and branch-3.5.X.
> >
> >
> We didn't used to have branches for releases and added them specifically
> for this reason - to allow commits while release in progress. Given the RM
> can (should) make the decision whether or not to pull things into a release
> candidate this seems fine with me (3.5 vs 3.5.x)
>
> Patrick
>
>
> > Either way I would keep our current branching strategy, but also would
> > like to hear everybody’s opinion.
> >
> > Regards,
> > Andor
> >
> >
> >
> >
> > > On 2019. Nov 11., at 22:19, Enrico Olivelli <eo...@gmail.com>
> wrote:
> > >
> > > Hello,
> > > in 3.5 we did a great work (in particular Andor and Norbert) in order
> to
> > > mavenize our repository and current we are performing releases from 3.5
> > > branch with Maven.
> > >
> > > For 3.6.0 I would like to try to enhance the procedure a bit and make
> it
> > > simpler, by using the Maven Release Plugin [1].
> > >
> > > I am drafting a new procedure [2], but it is still not ready,
> > > Once I am done with it the procedure will look like this [3] or [4]
> > >
> > > The major problem with the Maven release plugin is to update the
> versions
> > > on the C client, but I have found some trick so I am doing tests.
> > >
> > > I am just waiting for pending PRs that have been said to be nice to
> have
> > on
> > > 3.6.0 to land to master then I am confident we are ready to cut a
> release
> > >
> > > Any comments and help are welcome
> > >
> > > Enrico
> > >
> > > [1] https://maven.apache.org/maven-release/maven-release-plugin/
> > > [2]
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428
> > > [3]
> > https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
> > > [4] https://github.com/diennea/herddb/wiki/Release-guide
> >
> >
>
Re: Release procedure for 3.6.0 - new ideas with maven release plugin
Posted by Patrick Hunt <ph...@apache.org>.
On Wed, Jan 22, 2020 at 2:59 AM Andor Molnar <an...@apache.org> wrote:
> Hi,
>
> We started a discussion on Slack about branching/not branching for new
> releases like branch-3.5.6, branch-3.6.0, etc. I noticed that Enrico has
> not created branch for 3.6.0 and I’d like to talk about the motivations.
>
> Personally I’ve found the separate branch useful in the release process,
> because I didn’t have to ask people not to submit new patches on branch-3.5
> due to ongoing release process. On the flipside, fixes which have come up
> during release validation had to be submitted for 2 branches: branch-3.5
> and branch-3.5.X.
>
>
We didn't used to have branches for releases and added them specifically
for this reason - to allow commits while release in progress. Given the RM
can (should) make the decision whether or not to pull things into a release
candidate this seems fine with me (3.5 vs 3.5.x)
Patrick
> Either way I would keep our current branching strategy, but also would
> like to hear everybody’s opinion.
>
> Regards,
> Andor
>
>
>
>
> > On 2019. Nov 11., at 22:19, Enrico Olivelli <eo...@gmail.com> wrote:
> >
> > Hello,
> > in 3.5 we did a great work (in particular Andor and Norbert) in order to
> > mavenize our repository and current we are performing releases from 3.5
> > branch with Maven.
> >
> > For 3.6.0 I would like to try to enhance the procedure a bit and make it
> > simpler, by using the Maven Release Plugin [1].
> >
> > I am drafting a new procedure [2], but it is still not ready,
> > Once I am done with it the procedure will look like this [3] or [4]
> >
> > The major problem with the Maven release plugin is to update the versions
> > on the C client, but I have found some trick so I am doing tests.
> >
> > I am just waiting for pending PRs that have been said to be nice to have
> on
> > 3.6.0 to land to master then I am confident we are ready to cut a release
> >
> > Any comments and help are welcome
> >
> > Enrico
> >
> > [1] https://maven.apache.org/maven-release/maven-release-plugin/
> > [2]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135860428
> > [3]
> https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
> > [4] https://github.com/diennea/herddb/wiki/Release-guide
>
>