It's only versions burning, so find someone who's turning ...

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

It's only versions burning, so find someone who's turning ...

Benson Margulies
As a pessimist, I feel compelled to remind this group that we can
expect the release procedure to fail from time to time. Either the
build croaks in the middle of the maven-release-plugin, or someone
testing the release finds a blocking problem.

When this happens, it tends to trigger a religious war about the
management of git tags. I've lived through this several times, and I'd
love to avoid living through it again.

Let me describe three options:

1. Delete the tag and try again. If a release build fails after
tagging, or a vote fails, delete the tag from the official repo and
try again.

2. Abandon the version number. Once we tag 0.0.1, it's done. If it
can't be released, there will never be an 0.0.1, we try again with
0.0.2. Or 0.0.1a. Or whatever.

3. Use release candidates to reduce the possibility of a problem to a
very, very, small possibility.

Option 3 is how the Lucene PMC works. I think, myself, that it's the
best solution, so I'll detail it.

Assume that the goal is to release version x.y.x.

a. RM sets versions in poms to x.y.z-RC1-SNAPSHOT
b. RM runs full release procedure, including vote, for x.y.z-RC1.
c1. If the vote passes, that version is, in fact, _released_ in the
Apache legal sense.
c2. If the vote fails, the RM sets the versions to x.y.z-RC2-SNAPSHOT
and returns to b.
d. It cooks for a short period of time.
e. The RM sets the version to x.y.z-SNAPSHOT, and returns to b.

This procedure pretty nearly guarantees that a build or vote for x.y.z
will never fail, so the community can choose between (1) and (2) above
in a context where it will nearly never happen.

What you cannot do is vote based on an RC and then set the version to
a non-RC. This is a 'feature' of Maven.
Reply | Threaded
Open this post in threaded view
|

Re: It's only versions burning, so find someone who's turning ...

Adam Taft
Historically, I think we've done more of "2. Abandon the version number."

Procedure "3. Use release candidates" is only needed if there's a
compelling perspective that proper versions should have no gaps.  I
personally don't buy this so long as we document that there may be gaps (or
it can be easily inferred). But you're right, there are holy wars about
this topic.

One of the obvious problems with "3." is the extra vote cycle required. At
least for pre-1.0.0, this might be burdensome.  Perhaps we could reconsider
after 1.0.0?

I personally don't like deleting things, so I don't favor "1. Delete the
tag and try again."


On Thu, Jan 15, 2015 at 9:11 AM, Benson Margulies <[hidden email]>
wrote:

> As a pessimist, I feel compelled to remind this group that we can
> expect the release procedure to fail from time to time. Either the
> build croaks in the middle of the maven-release-plugin, or someone
> testing the release finds a blocking problem.
>
> When this happens, it tends to trigger a religious war about the
> management of git tags. I've lived through this several times, and I'd
> love to avoid living through it again.
>
> Let me describe three options:
>
> 1. Delete the tag and try again. If a release build fails after
> tagging, or a vote fails, delete the tag from the official repo and
> try again.
>
> 2. Abandon the version number. Once we tag 0.0.1, it's done. If it
> can't be released, there will never be an 0.0.1, we try again with
> 0.0.2. Or 0.0.1a. Or whatever.
>
> 3. Use release candidates to reduce the possibility of a problem to a
> very, very, small possibility.
>
> Option 3 is how the Lucene PMC works. I think, myself, that it's the
> best solution, so I'll detail it.
>
> Assume that the goal is to release version x.y.x.
>
> a. RM sets versions in poms to x.y.z-RC1-SNAPSHOT
> b. RM runs full release procedure, including vote, for x.y.z-RC1.
> c1. If the vote passes, that version is, in fact, _released_ in the
> Apache legal sense.
> c2. If the vote fails, the RM sets the versions to x.y.z-RC2-SNAPSHOT
> and returns to b.
> d. It cooks for a short period of time.
> e. The RM sets the version to x.y.z-SNAPSHOT, and returns to b.
>
> This procedure pretty nearly guarantees that a build or vote for x.y.z
> will never fail, so the community can choose between (1) and (2) above
> in a context where it will nearly never happen.
>
> What you cannot do is vote based on an RC and then set the version to
> a non-RC. This is a 'feature' of Maven.
>
Reply | Threaded
Open this post in threaded view
|

Re: It's only versions burning, so find someone who's turning ...

Joe Witt
Benson,

First of all thanks for bringing this up ahead of it being an issue.
Definitely a good way to avoid problems.

How in option 3 do you go from 'x.y.z-RC1' to x.y.z?  Is it because of the
part "e"?  If so how does this reduce to a low possibility the failure
scenario?  Does this just make it so the only remaining failure could be
the maven release process itself (rather than input from community members)?

I would personally be inclined to option 2.  Can you share what you think
are the drawbacks to option 2?

Thanks
Joe


On Thu, Jan 15, 2015 at 9:23 AM, Adam Taft <[hidden email]> wrote:

> Historically, I think we've done more of "2. Abandon the version number."
>
> Procedure "3. Use release candidates" is only needed if there's a
> compelling perspective that proper versions should have no gaps.  I
> personally don't buy this so long as we document that there may be gaps (or
> it can be easily inferred). But you're right, there are holy wars about
> this topic.
>
> One of the obvious problems with "3." is the extra vote cycle required. At
> least for pre-1.0.0, this might be burdensome.  Perhaps we could reconsider
> after 1.0.0?
>
> I personally don't like deleting things, so I don't favor "1. Delete the
> tag and try again."
>
>
> On Thu, Jan 15, 2015 at 9:11 AM, Benson Margulies <[hidden email]>
> wrote:
>
> > As a pessimist, I feel compelled to remind this group that we can
> > expect the release procedure to fail from time to time. Either the
> > build croaks in the middle of the maven-release-plugin, or someone
> > testing the release finds a blocking problem.
> >
> > When this happens, it tends to trigger a religious war about the
> > management of git tags. I've lived through this several times, and I'd
> > love to avoid living through it again.
> >
> > Let me describe three options:
> >
> > 1. Delete the tag and try again. If a release build fails after
> > tagging, or a vote fails, delete the tag from the official repo and
> > try again.
> >
> > 2. Abandon the version number. Once we tag 0.0.1, it's done. If it
> > can't be released, there will never be an 0.0.1, we try again with
> > 0.0.2. Or 0.0.1a. Or whatever.
> >
> > 3. Use release candidates to reduce the possibility of a problem to a
> > very, very, small possibility.
> >
> > Option 3 is how the Lucene PMC works. I think, myself, that it's the
> > best solution, so I'll detail it.
> >
> > Assume that the goal is to release version x.y.x.
> >
> > a. RM sets versions in poms to x.y.z-RC1-SNAPSHOT
> > b. RM runs full release procedure, including vote, for x.y.z-RC1.
> > c1. If the vote passes, that version is, in fact, _released_ in the
> > Apache legal sense.
> > c2. If the vote fails, the RM sets the versions to x.y.z-RC2-SNAPSHOT
> > and returns to b.
> > d. It cooks for a short period of time.
> > e. The RM sets the version to x.y.z-SNAPSHOT, and returns to b.
> >
> > This procedure pretty nearly guarantees that a build or vote for x.y.z
> > will never fail, so the community can choose between (1) and (2) above
> > in a context where it will nearly never happen.
> >
> > What you cannot do is vote based on an RC and then set the version to
> > a non-RC. This is a 'feature' of Maven.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: It's only versions burning, so find someone who's turning ...

Benson Margulies
Some people hate option 2 because version gaps offend their sense of
harmony. I'm not one of those people, I've just spent a lot of time
around them. So, to clarify, if gaps don't bother this group, by all
means, take (2). And edit the page I just created to say so, and to
specify precisely what form of (2) you want: 0.0.1 -> 0.0.2 or 0.0.1
-> 0.0.1a.

Here's how the RC thing works out in practice.

x.y.z-RC23 passes. You change _nothing_ except the version numbers in
the poms. You go through the release procedure again. Something very
sad has to be going on if that fails.


On Thu, Jan 15, 2015 at 9:36 AM, Joe Witt <[hidden email]> wrote:

> Benson,
>
> First of all thanks for bringing this up ahead of it being an issue.
> Definitely a good way to avoid problems.
>
> How in option 3 do you go from 'x.y.z-RC1' to x.y.z?  Is it because of the
> part "e"?  If so how does this reduce to a low possibility the failure
> scenario?  Does this just make it so the only remaining failure could be
> the maven release process itself (rather than input from community members)?
>
> I would personally be inclined to option 2.  Can you share what you think
> are the drawbacks to option 2?
>
> Thanks
> Joe
>
>
> On Thu, Jan 15, 2015 at 9:23 AM, Adam Taft <[hidden email]> wrote:
>
>> Historically, I think we've done more of "2. Abandon the version number."
>>
>> Procedure "3. Use release candidates" is only needed if there's a
>> compelling perspective that proper versions should have no gaps.  I
>> personally don't buy this so long as we document that there may be gaps (or
>> it can be easily inferred). But you're right, there are holy wars about
>> this topic.
>>
>> One of the obvious problems with "3." is the extra vote cycle required. At
>> least for pre-1.0.0, this might be burdensome.  Perhaps we could reconsider
>> after 1.0.0?
>>
>> I personally don't like deleting things, so I don't favor "1. Delete the
>> tag and try again."
>>
>>
>> On Thu, Jan 15, 2015 at 9:11 AM, Benson Margulies <[hidden email]>
>> wrote:
>>
>> > As a pessimist, I feel compelled to remind this group that we can
>> > expect the release procedure to fail from time to time. Either the
>> > build croaks in the middle of the maven-release-plugin, or someone
>> > testing the release finds a blocking problem.
>> >
>> > When this happens, it tends to trigger a religious war about the
>> > management of git tags. I've lived through this several times, and I'd
>> > love to avoid living through it again.
>> >
>> > Let me describe three options:
>> >
>> > 1. Delete the tag and try again. If a release build fails after
>> > tagging, or a vote fails, delete the tag from the official repo and
>> > try again.
>> >
>> > 2. Abandon the version number. Once we tag 0.0.1, it's done. If it
>> > can't be released, there will never be an 0.0.1, we try again with
>> > 0.0.2. Or 0.0.1a. Or whatever.
>> >
>> > 3. Use release candidates to reduce the possibility of a problem to a
>> > very, very, small possibility.
>> >
>> > Option 3 is how the Lucene PMC works. I think, myself, that it's the
>> > best solution, so I'll detail it.
>> >
>> > Assume that the goal is to release version x.y.x.
>> >
>> > a. RM sets versions in poms to x.y.z-RC1-SNAPSHOT
>> > b. RM runs full release procedure, including vote, for x.y.z-RC1.
>> > c1. If the vote passes, that version is, in fact, _released_ in the
>> > Apache legal sense.
>> > c2. If the vote fails, the RM sets the versions to x.y.z-RC2-SNAPSHOT
>> > and returns to b.
>> > d. It cooks for a short period of time.
>> > e. The RM sets the version to x.y.z-SNAPSHOT, and returns to b.
>> >
>> > This procedure pretty nearly guarantees that a build or vote for x.y.z
>> > will never fail, so the community can choose between (1) and (2) above
>> > in a context where it will nearly never happen.
>> >
>> > What you cannot do is vote based on an RC and then set the version to
>> > a non-RC. This is a 'feature' of Maven.
>> >
>>
Reply | Threaded
Open this post in threaded view
|

Re: It's only versions burning, so find someone who's turning ...

Joey Echeverria
The one thing I really like about the RC process is it makes it easier in my mind to draw a line in the sand over when certain code changes are not allowed. 


Basically, when the RC process starts, the only changes allowed in that release branch are issues that caused the vote to fail.




From an ASF perspective, the only things that matter for a release is meeting the legal requirements. Having the RC process lets the technical side of release voting to play out.




I don't personally like version skipping, but I don't feel any reason to convince others. So long as the order of releases is clearly documented, there shouldn't be any issue if y'all prefer option 2.




FWIW, in Kite we follow option 1. We stage the release and vote on it. If the vote fails, we rollback the release and delete the tag. When we run the release again, the maven release plugin recreates the tag. 




-Joey



Joey Echeverria

On Thu, Jan 15, 2015 at 6:48 AM, Benson Margulies <[hidden email]>
wrote:

> Some people hate option 2 because version gaps offend their sense of
> harmony. I'm not one of those people, I've just spent a lot of time
> around them. So, to clarify, if gaps don't bother this group, by all
> means, take (2). And edit the page I just created to say so, and to
> specify precisely what form of (2) you want: 0.0.1 -> 0.0.2 or 0.0.1
> -> 0.0.1a.
> Here's how the RC thing works out in practice.
> x.y.z-RC23 passes. You change _nothing_ except the version numbers in
> the poms. You go through the release procedure again. Something very
> sad has to be going on if that fails.
> On Thu, Jan 15, 2015 at 9:36 AM, Joe Witt <[hidden email]> wrote:
>> Benson,
>>
>> First of all thanks for bringing this up ahead of it being an issue.
>> Definitely a good way to avoid problems.
>>
>> How in option 3 do you go from 'x.y.z-RC1' to x.y.z?  Is it because of the
>> part "e"?  If so how does this reduce to a low possibility the failure
>> scenario?  Does this just make it so the only remaining failure could be
>> the maven release process itself (rather than input from community members)?
>>
>> I would personally be inclined to option 2.  Can you share what you think
>> are the drawbacks to option 2?
>>
>> Thanks
>> Joe
>>
>>
>> On Thu, Jan 15, 2015 at 9:23 AM, Adam Taft <[hidden email]> wrote:
>>
>>> Historically, I think we've done more of "2. Abandon the version number."
>>>
>>> Procedure "3. Use release candidates" is only needed if there's a
>>> compelling perspective that proper versions should have no gaps.  I
>>> personally don't buy this so long as we document that there may be gaps (or
>>> it can be easily inferred). But you're right, there are holy wars about
>>> this topic.
>>>
>>> One of the obvious problems with "3." is the extra vote cycle required. At
>>> least for pre-1.0.0, this might be burdensome.  Perhaps we could reconsider
>>> after 1.0.0?
>>>
>>> I personally don't like deleting things, so I don't favor "1. Delete the
>>> tag and try again."
>>>
>>>
>>> On Thu, Jan 15, 2015 at 9:11 AM, Benson Margulies <[hidden email]>
>>> wrote:
>>>
>>> > As a pessimist, I feel compelled to remind this group that we can
>>> > expect the release procedure to fail from time to time. Either the
>>> > build croaks in the middle of the maven-release-plugin, or someone
>>> > testing the release finds a blocking problem.
>>> >
>>> > When this happens, it tends to trigger a religious war about the
>>> > management of git tags. I've lived through this several times, and I'd
>>> > love to avoid living through it again.
>>> >
>>> > Let me describe three options:
>>> >
>>> > 1. Delete the tag and try again. If a release build fails after
>>> > tagging, or a vote fails, delete the tag from the official repo and
>>> > try again.
>>> >
>>> > 2. Abandon the version number. Once we tag 0.0.1, it's done. If it
>>> > can't be released, there will never be an 0.0.1, we try again with
>>> > 0.0.2. Or 0.0.1a. Or whatever.
>>> >
>>> > 3. Use release candidates to reduce the possibility of a problem to a
>>> > very, very, small possibility.
>>> >
>>> > Option 3 is how the Lucene PMC works. I think, myself, that it's the
>>> > best solution, so I'll detail it.
>>> >
>>> > Assume that the goal is to release version x.y.x.
>>> >
>>> > a. RM sets versions in poms to x.y.z-RC1-SNAPSHOT
>>> > b. RM runs full release procedure, including vote, for x.y.z-RC1.
>>> > c1. If the vote passes, that version is, in fact, _released_ in the
>>> > Apache legal sense.
>>> > c2. If the vote fails, the RM sets the versions to x.y.z-RC2-SNAPSHOT
>>> > and returns to b.
>>> > d. It cooks for a short period of time.
>>> > e. The RM sets the version to x.y.z-SNAPSHOT, and returns to b.
>>> >
>>> > This procedure pretty nearly guarantees that a build or vote for x.y.z
>>> > will never fail, so the community can choose between (1) and (2) above
>>> > in a context where it will nearly never happen.
>>> >
>>> > What you cannot do is vote based on an RC and then set the version to
>>> > a non-RC. This is a 'feature' of Maven.
>>> >
>>>
Reply | Threaded
Open this post in threaded view
|

Re: It's only versions burning, so find someone who's turning ...

Mike Drob
Option 1 may also cause issues with downstream mirrors. For example, if you
push a tag and it gets mirrored somewhere (say... GitHub) and then you
delete and push a new tag, then the new tag may or may not be properly
reflected in the mirror. It complicates things further if folks have forks
of the GH repo, and their tags get out of sync. Now, generally this won't
propagate anywhere relevant, but sometimes people will end up with strange
errors that they won't be able to otherwise explain.

Mike

On Thu, Jan 15, 2015 at 8:14 AM, Joey Echeverria <[hidden email]> wrote:

> The one thing I really like about the RC process is it makes it easier in
> my mind to draw a line in the sand over when certain code changes are not
> allowed.
>
>
> Basically, when the RC process starts, the only changes allowed in that
> release branch are issues that caused the vote to fail.
>
>
>
>
> From an ASF perspective, the only things that matter for a release is
> meeting the legal requirements. Having the RC process lets the technical
> side of release voting to play out.
>
>
>
>
> I don't personally like version skipping, but I don't feel any reason to
> convince others. So long as the order of releases is clearly documented,
> there shouldn't be any issue if y'all prefer option 2.
>
>
>
>
> FWIW, in Kite we follow option 1. We stage the release and vote on it. If
> the vote fails, we rollback the release and delete the tag. When we run the
> release again, the maven release plugin recreates the tag.
>
>
>
>
> -Joey
>
>
> —
> Joey Echeverria
>
> On Thu, Jan 15, 2015 at 6:48 AM, Benson Margulies <[hidden email]>
> wrote:
>
> > Some people hate option 2 because version gaps offend their sense of
> > harmony. I'm not one of those people, I've just spent a lot of time
> > around them. So, to clarify, if gaps don't bother this group, by all
> > means, take (2). And edit the page I just created to say so, and to
> > specify precisely what form of (2) you want: 0.0.1 -> 0.0.2 or 0.0.1
> > -> 0.0.1a.
> > Here's how the RC thing works out in practice.
> > x.y.z-RC23 passes. You change _nothing_ except the version numbers in
> > the poms. You go through the release procedure again. Something very
> > sad has to be going on if that fails.
> > On Thu, Jan 15, 2015 at 9:36 AM, Joe Witt <[hidden email]> wrote:
> >> Benson,
> >>
> >> First of all thanks for bringing this up ahead of it being an issue.
> >> Definitely a good way to avoid problems.
> >>
> >> How in option 3 do you go from 'x.y.z-RC1' to x.y.z?  Is it because of
> the
> >> part "e"?  If so how does this reduce to a low possibility the failure
> >> scenario?  Does this just make it so the only remaining failure could be
> >> the maven release process itself (rather than input from community
> members)?
> >>
> >> I would personally be inclined to option 2.  Can you share what you
> think
> >> are the drawbacks to option 2?
> >>
> >> Thanks
> >> Joe
> >>
> >>
> >> On Thu, Jan 15, 2015 at 9:23 AM, Adam Taft <[hidden email]> wrote:
> >>
> >>> Historically, I think we've done more of "2. Abandon the version
> number."
> >>>
> >>> Procedure "3. Use release candidates" is only needed if there's a
> >>> compelling perspective that proper versions should have no gaps.  I
> >>> personally don't buy this so long as we document that there may be
> gaps (or
> >>> it can be easily inferred). But you're right, there are holy wars about
> >>> this topic.
> >>>
> >>> One of the obvious problems with "3." is the extra vote cycle
> required. At
> >>> least for pre-1.0.0, this might be burdensome.  Perhaps we could
> reconsider
> >>> after 1.0.0?
> >>>
> >>> I personally don't like deleting things, so I don't favor "1. Delete
> the
> >>> tag and try again."
> >>>
> >>>
> >>> On Thu, Jan 15, 2015 at 9:11 AM, Benson Margulies <
> [hidden email]>
> >>> wrote:
> >>>
> >>> > As a pessimist, I feel compelled to remind this group that we can
> >>> > expect the release procedure to fail from time to time. Either the
> >>> > build croaks in the middle of the maven-release-plugin, or someone
> >>> > testing the release finds a blocking problem.
> >>> >
> >>> > When this happens, it tends to trigger a religious war about the
> >>> > management of git tags. I've lived through this several times, and
> I'd
> >>> > love to avoid living through it again.
> >>> >
> >>> > Let me describe three options:
> >>> >
> >>> > 1. Delete the tag and try again. If a release build fails after
> >>> > tagging, or a vote fails, delete the tag from the official repo and
> >>> > try again.
> >>> >
> >>> > 2. Abandon the version number. Once we tag 0.0.1, it's done. If it
> >>> > can't be released, there will never be an 0.0.1, we try again with
> >>> > 0.0.2. Or 0.0.1a. Or whatever.
> >>> >
> >>> > 3. Use release candidates to reduce the possibility of a problem to a
> >>> > very, very, small possibility.
> >>> >
> >>> > Option 3 is how the Lucene PMC works. I think, myself, that it's the
> >>> > best solution, so I'll detail it.
> >>> >
> >>> > Assume that the goal is to release version x.y.x.
> >>> >
> >>> > a. RM sets versions in poms to x.y.z-RC1-SNAPSHOT
> >>> > b. RM runs full release procedure, including vote, for x.y.z-RC1.
> >>> > c1. If the vote passes, that version is, in fact, _released_ in the
> >>> > Apache legal sense.
> >>> > c2. If the vote fails, the RM sets the versions to x.y.z-RC2-SNAPSHOT
> >>> > and returns to b.
> >>> > d. It cooks for a short period of time.
> >>> > e. The RM sets the version to x.y.z-SNAPSHOT, and returns to b.
> >>> >
> >>> > This procedure pretty nearly guarantees that a build or vote for
> x.y.z
> >>> > will never fail, so the community can choose between (1) and (2)
> above
> >>> > in a context where it will nearly never happen.
> >>> >
> >>> > What you cannot do is vote based on an RC and then set the version to
> >>> > a non-RC. This is a 'feature' of Maven.
> >>> >
> >>>
>