[DISCUSS] How to generate RC's

[Mike Drob <ma...@cloudera.com>]

Taking this conversation from IRC because it probably needs to be on the
mailing list at some point. Also, we'll want to update the site when we
have something we are happy with. Thanks to Christopher and Josh for the
thoughts they've already contributed to the discussion.

We need a standard procedure for generating RCs that is:
1) Easily reproducible
2) Compatible with ongoing development
3) Compatible with our git branching model.

The proposed process is:
1) Create an RC branch named x.y.z-rcN from (the tip of) x.y.z-SNAPSHOT
2) Commit pom version changes to the branch, tag as rc, and push
3) Perform testing and voting as necessary
3a) If the vote fails, make corrections and start over at 1)
4) After a vote passes, tag the release on the same commit that was the rc
5) Apply additional pom changes (i.e. increment to next SNAPSHOT version)
6) Create a new development branch x.y.a-SNAPSHOT based on the current tip
of x.y.z-SNAPSHOT
7) Merge tag + version increment into x.y.a-SNAPSHOT branch
8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT

After having typed that all out it kind of seems like a lot of steps to go
through, but on the other hand, we're not going to be doing everything at
once anyway.

Additional feedback would be awesome.

Mike

Re: [DISCUSS] How to generate RC's

[Josh Elser <jo...@gmail.com>]

Typically, if someone wants to run cluster tests against a release, this is
done before the RC vote is called due to the obvious time constraints of
running a three day test in the span of a three day vote.

You still should have time to run each other test if you so choose. But
again, I don't think people typically run tests outside of the unit and
functional ones besides the vote caller. I could be mistaken though.
On Feb 5, 2014 8:20 AM, "Sean Busbey" <bu...@cloudera.com> wrote:

> One thing I've just realized, the 72 hour window on an RC doesn't give me
> enough time to run the full release test suite myself. It seems like that's
> going to limit the variety of cluster results we can get included for a
> release.
>
>
> -Sean
>
> On Tue, Feb 4, 2014 at 10:50 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Some extra notes that I ran into with not working against
> > maven-release-plugin.
> >
> > The plugin will prompt for the release version, the tag name, and the
> next
> > development version. For 1.5.1, we really want to give 1.5.1, 1.5.1-rcN,
> > 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in
> the
> > pom which is undesirable.
> >
> > To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT
> > (which results in the proper values in the pom), created the 1.5.1-rcN
> > branch from the release plugin commit for 1.5.1, edited scm.tag in
> > release.properties to be 1.5.1-rcN instead of 1.5.1, and then pushed the
> > 1.5.1-rcN branch. Then, release:perform will actually build and stage the
> > right code.
> >
> > Not as simple as it might be, but at least it works and semi-aligns with
> > what we described originally.
> >
> >
> > On 1/13/14, 11:16 AM, Josh Elser wrote:
> >
> >> On 1/13/14, 10:17 AM, Mike Drob wrote:
> >>
> >>> #1 - No strong opinions.
> >>> #2 - I want to make the transition for committers from one branch to
> the
> >>> next as painless as possible. In particular, I'm worried that somebody
> >>> will
> >>> not realize they need to switch branched and accidentally push e.g.
> >>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
> >>> want just a general 1.4 branch to deal with this case. (And similarly
> >>> applied to the other lines.)
> >>>
> >>> What do you mean "put down the info... with the git-archive?" Listing
> the
> >>> exact command?
> >>>
> >>
> >> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate)
> >> shouldn't be harder than ensuring you have a GPG created.
> >>
> >>  Another thought I had on this - what kind of tags are we using?
> >>> Lightweight? Annotated? Signed?
> >>>
> >>
> >> I think Christopher had recommended a signed tag. ACCUMULO-1468 should
> >> have that definitively, but I'm not really up to date on what
> >> common/good practices are here.
> >>
> >>  I think 1.4.4 has been the only git release, and I used a lightweight
> tag
> >>> due to ignorance rather than choice.
> >>>
> >>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
> >>> wrote:
> >>>
> >>>  For #1, we typically haven't had a need/desire to keep around how we
> got
> >>>> to a release (the RCs), but just the final release itself. If this is
> >>>> something that has merit to it (besides trying to avoid the same
> >>>> mistakes
> >>>> in future releases), I can't think of a good one. Maybe putting an
> RC-X
> >>>> note in the commit message would be sufficient?
> >>>>
> >>>> #2, we could. I think the way Mike has this laid out is a little more
> >>>> secure against people working already working on things for the next
> >>>> release (or people who are still working on known bugs in a RC), but
> >>>> they
> >>>> both do the same thing.
> >>>>
> >>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document
> >>>> this. Perhaps we can also put down the info you used for 1.4.4 with
> the
> >>>> git-archive? We also should transcribe the mvn-deploy info from
> >>>> Christopher
> >>>> that I have linked in the ticket.
> >>>>
> >>>>
> >>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
> >>>>
> >>>>  Overall, the process looks good, and I agree with Josh's
> clarification.
> >>>>> Two
> >>>>> pieces of feedback:
> >>>>>
> >>>>> 1. Step 8 removes a recording of the history leading to the release.
> >>>>> For
> >>>>> example, suppose rc1 is no good, and it takes three commits to get
> >>>>> to rc2,
> >>>>> which passes. When we remove the rc1 branch, how do we easily figure
> >>>>> out
> >>>>> months later which commit rc1 had been based on? (Look at an rc1 JAR
> >>>>> manifest for the hash? eww.) On the other hand, I can see a benefit
> in
> >>>>> removing inactive branches and tags to reduce clutter.
> >>>>>
> >>>>> 2. We could save a step, namely #7, by applying the increment to
> >>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
> >>>>> instead of
> >>>>> on x.y.z. However, this would not leave a linear history, so I leave
> >>>>> it to
> >>>>> the more Git-savvy to decide if that is important in this case.
> >>>>>
> >>>>> Bill H
> >>>>>
> >>>>>
> >>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>   Looks good to me. I don't think it's too much work in the big
> >>>>> picture --
> >>>>>
> >>>>>> it's what's necessary to get it done properly given the tool.
> >>>>>>
> >>>>>> The only ambiguity I see is in 3a), "make corrections _on
> >>>>>> x.y.z-SNAPSHOT_".
> >>>>>>
> >>>>>> Let's make sure this (assuming there aren't any objections) gets up
> on
> >>>>>> the
> >>>>>> site.
> >>>>>>
> >>>>>> - Josh
> >>>>>>
> >>>>>>
> >>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
> >>>>>>
> >>>>>>   Taking this conversation from IRC because it probably needs to be
> >>>>>> on the
> >>>>>>
> >>>>>>> mailing list at some point. Also, we'll want to update the site
> >>>>>>> when we
> >>>>>>> have something we are happy with. Thanks to Christopher and Josh
> >>>>>>> for the
> >>>>>>> thoughts they've already contributed to the discussion.
> >>>>>>>
> >>>>>>> We need a standard procedure for generating RCs that is:
> >>>>>>> 1) Easily reproducible
> >>>>>>> 2) Compatible with ongoing development
> >>>>>>> 3) Compatible with our git branching model.
> >>>>>>>
> >>>>>>> The proposed process is:
> >>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
> >>>>>>> x.y.z-SNAPSHOT
> >>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
> >>>>>>> 3) Perform testing and voting as necessary
> >>>>>>> 3a) If the vote fails, make corrections and start over at 1)
> >>>>>>> 4) After a vote passes, tag the release on the same commit that
> >>>>>>> was the
> >>>>>>> rc
> >>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
> >>>>>>> version)
> >>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
> >>>>>>> current
> >>>>>>> tip
> >>>>>>> of x.y.z-SNAPSHOT
> >>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
> >>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
> >>>>>>>
> >>>>>>> After having typed that all out it kind of seems like a lot of
> >>>>>>> steps to
> >>>>>>> go
> >>>>>>> through, but on the other hand, we're not going to be doing
> >>>>>>> everything
> >>>>>>> at
> >>>>>>> once anyway.
> >>>>>>>
> >>>>>>> Additional feedback would be awesome.
> >>>>>>>
> >>>>>>> Mike
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
>

Re: [DISCUSS] How to generate RC's

[Sean Busbey <bu...@cloudera.com>]

One thing I've just realized, the 72 hour window on an RC doesn't give me
enough time to run the full release test suite myself. It seems like that's
going to limit the variety of cluster results we can get included for a
release.


-Sean

On Tue, Feb 4, 2014 at 10:50 PM, Josh Elser <jo...@gmail.com> wrote:

> Some extra notes that I ran into with not working against
> maven-release-plugin.
>
> The plugin will prompt for the release version, the tag name, and the next
> development version. For 1.5.1, we really want to give 1.5.1, 1.5.1-rcN,
> 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in the
> pom which is undesirable.
>
> To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT
> (which results in the proper values in the pom), created the 1.5.1-rcN
> branch from the release plugin commit for 1.5.1, edited scm.tag in
> release.properties to be 1.5.1-rcN instead of 1.5.1, and then pushed the
> 1.5.1-rcN branch. Then, release:perform will actually build and stage the
> right code.
>
> Not as simple as it might be, but at least it works and semi-aligns with
> what we described originally.
>
>
> On 1/13/14, 11:16 AM, Josh Elser wrote:
>
>> On 1/13/14, 10:17 AM, Mike Drob wrote:
>>
>>> #1 - No strong opinions.
>>> #2 - I want to make the transition for committers from one branch to the
>>> next as painless as possible. In particular, I'm worried that somebody
>>> will
>>> not realize they need to switch branched and accidentally push e.g.
>>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
>>> want just a general 1.4 branch to deal with this case. (And similarly
>>> applied to the other lines.)
>>>
>>> What do you mean "put down the info... with the git-archive?" Listing the
>>> exact command?
>>>
>>
>> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate)
>> shouldn't be harder than ensuring you have a GPG created.
>>
>>  Another thought I had on this - what kind of tags are we using?
>>> Lightweight? Annotated? Signed?
>>>
>>
>> I think Christopher had recommended a signed tag. ACCUMULO-1468 should
>> have that definitively, but I'm not really up to date on what
>> common/good practices are here.
>>
>>  I think 1.4.4 has been the only git release, and I used a lightweight tag
>>> due to ignorance rather than choice.
>>>
>>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
>>> wrote:
>>>
>>>  For #1, we typically haven't had a need/desire to keep around how we got
>>>> to a release (the RCs), but just the final release itself. If this is
>>>> something that has merit to it (besides trying to avoid the same
>>>> mistakes
>>>> in future releases), I can't think of a good one. Maybe putting an RC-X
>>>> note in the commit message would be sufficient?
>>>>
>>>> #2, we could. I think the way Mike has this laid out is a little more
>>>> secure against people working already working on things for the next
>>>> release (or people who are still working on known bugs in a RC), but
>>>> they
>>>> both do the same thing.
>>>>
>>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document
>>>> this. Perhaps we can also put down the info you used for 1.4.4 with the
>>>> git-archive? We also should transcribe the mvn-deploy info from
>>>> Christopher
>>>> that I have linked in the ticket.
>>>>
>>>>
>>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>>>>
>>>>  Overall, the process looks good, and I agree with Josh's clarification.
>>>>> Two
>>>>> pieces of feedback:
>>>>>
>>>>> 1. Step 8 removes a recording of the history leading to the release.
>>>>> For
>>>>> example, suppose rc1 is no good, and it takes three commits to get
>>>>> to rc2,
>>>>> which passes. When we remove the rc1 branch, how do we easily figure
>>>>> out
>>>>> months later which commit rc1 had been based on? (Look at an rc1 JAR
>>>>> manifest for the hash? eww.) On the other hand, I can see a benefit in
>>>>> removing inactive branches and tags to reduce clutter.
>>>>>
>>>>> 2. We could save a step, namely #7, by applying the increment to
>>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
>>>>> instead of
>>>>> on x.y.z. However, this would not leave a linear history, so I leave
>>>>> it to
>>>>> the more Git-savvy to decide if that is important in this case.
>>>>>
>>>>> Bill H
>>>>>
>>>>>
>>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>   Looks good to me. I don't think it's too much work in the big
>>>>> picture --
>>>>>
>>>>>> it's what's necessary to get it done properly given the tool.
>>>>>>
>>>>>> The only ambiguity I see is in 3a), "make corrections _on
>>>>>> x.y.z-SNAPSHOT_".
>>>>>>
>>>>>> Let's make sure this (assuming there aren't any objections) gets up on
>>>>>> the
>>>>>> site.
>>>>>>
>>>>>> - Josh
>>>>>>
>>>>>>
>>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>>>>
>>>>>>   Taking this conversation from IRC because it probably needs to be
>>>>>> on the
>>>>>>
>>>>>>> mailing list at some point. Also, we'll want to update the site
>>>>>>> when we
>>>>>>> have something we are happy with. Thanks to Christopher and Josh
>>>>>>> for the
>>>>>>> thoughts they've already contributed to the discussion.
>>>>>>>
>>>>>>> We need a standard procedure for generating RCs that is:
>>>>>>> 1) Easily reproducible
>>>>>>> 2) Compatible with ongoing development
>>>>>>> 3) Compatible with our git branching model.
>>>>>>>
>>>>>>> The proposed process is:
>>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
>>>>>>> x.y.z-SNAPSHOT
>>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>>>>> 3) Perform testing and voting as necessary
>>>>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>>>>> 4) After a vote passes, tag the release on the same commit that
>>>>>>> was the
>>>>>>> rc
>>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>>>>> version)
>>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
>>>>>>> current
>>>>>>> tip
>>>>>>> of x.y.z-SNAPSHOT
>>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>>>>
>>>>>>> After having typed that all out it kind of seems like a lot of
>>>>>>> steps to
>>>>>>> go
>>>>>>> through, but on the other hand, we're not going to be doing
>>>>>>> everything
>>>>>>> at
>>>>>>> once anyway.
>>>>>>>
>>>>>>> Additional feedback would be awesome.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>

Re: [DISCUSS] How to generate RC's

[Sean Busbey <bu...@cloudera.com>]

On Feb 11, 2014 3:29 PM, "Josh Elser" <jo...@gmail.com> wrote:
>
> I think I mentioned this earlier/elsewhere already, but I'd prefer better
communication by parties interesting in testing so that when the RC is
called, we already have the day+ duration tests already run.
>
> IMO I don't think the voting time is the right time to be trying to find
"distributed system" level bugs. That should be time focused on judging the
release itself -- packaging (tarball, rpm, debs, etc), ASF requirements
(signing, hashes), scripts (init.d, bin/*), basic user interaction, and the
like.
>

For this to work, we'd need a better way to denote what's getting tested.
An RC tag provides an easy reference.

At the very least, we'd need to enforce having the release manager for the
branch act as a gatekeeper on additional changes once a
before-rc-release-testing-phase got started.

This wouldn't require starting the next dev branches while we're handling a
release. Instead, blocked changes could just be stored as patches on their
relevant jiras. For example, Avro does this for breaking changes.

Re: [DISCUSS] How to generate RC's

[Mike Drob <ma...@cloudera.com>]

For what it's worth, Hadoop 2.3 rc0 went out today with a 7 day vote.

http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201402.mbox/%3CDA05A835-B25D-4922-8573-46BBB8807ABE%40hortonworks.com%3E


On Tue, Feb 11, 2014 at 1:28 PM, Josh Elser <jo...@gmail.com> wrote:

> I think I mentioned this earlier/elsewhere already, but I'd prefer better
> communication by parties interesting in testing so that when the RC is
> called, we already have the day+ duration tests already run.
>
> IMO I don't think the voting time is the right time to be trying to find
> "distributed system" level bugs. That should be time focused on judging the
> release itself -- packaging (tarball, rpm, debs, etc), ASF requirements
> (signing, hashes), scripts (init.d, bin/*), basic user interaction, and the
> like.
>
>
> On 2/11/14, 4:17 PM, Mike Drob wrote:
>
>> One more change that I'd like to see is expanding the voting period beyond
>> 72 hours. If I want to test the RC on different hardware/OS/versions than
>> the release manager has done, then I need a longer time frame than what is
>> currently provided.
>>
>>
>> On Thu, Feb 6, 2014 at 7:54 PM, Christopher <ct...@apache.org> wrote:
>>
>>  I say don't bump until the vote passes or fails. If it passes, either
>>> drop the branch, or if there are commits since the RC was made, no-op
>>> merge in the tag, bump the version, and rename the branch. The version
>>> doesn't matter until later.
>>>
>>> I believe the release plugin has a goal to bump versions only, so that
>>> part is pretty easy.
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Thu, Feb 6, 2014 at 3:49 PM, Josh Elser <jo...@gmail.com> wrote:
>>>
>>>> Changing the tagNameFormat would remove an extra manual step which is
>>>>
>>> likely
>>>
>>>> good. I'm not sure about how the local checkout stuff works and if there
>>>>
>>> is
>>>
>>>> something easier we can do there.
>>>>
>>>> One extra thing that I've found that is a little awkward to work with
>>>> now
>>>> that we're in a vote, is that we almost want to freeze the
>>>> 1.5.1-SNAPSHOT
>>>> branch. I haven't been able to come up with what we should do with the
>>>> branch for the version we're trying to release considering that at least
>>>>
>>> one
>>>
>>>> RC will probably fail.
>>>>
>>>> We *could* bump the 1.5.1-SNAPSHOT branch to 1.5.2-SNAPSHOT in the poms,
>>>>
>>> but
>>>
>>>> then we would need to revert that every time we fail a RC. That's
>>>>
>>> probably
>>>
>>>> the best solution that doesn't try to work around the
>>>>
>>> maven-release-plugin,
>>>
>>>> but it does leave some nice blemishes in the history.
>>>>
>>>>
>>>> On 2/5/14, 5:16 PM, Christopher wrote:
>>>>
>>>>>
>>>>> We should change tagNameFormat for the maven-release-plugin to
>>>>> @{project.version}, so you can just hit "enter" at that field to
>>>>> accept the default. You may still need to do the rest of what you did
>>>>> (or something similar) to push to a different branch or tag, though...
>>>>> I'm not sure (I wonder if you could just let it build the local tag it
>>>>> creates instead of editing scm.tag), and simply don't push that tag
>>>>> until you change its name to one with -rcX.
>>>>>
>>>>> --
>>>>> Christopher L Tubbs II
>>>>> http://gravatar.com/ctubbsii
>>>>>
>>>>>
>>>>> On Tue, Feb 4, 2014 at 11:50 PM, Josh Elser <jo...@gmail.com>
>>>>>
>>>> wrote:
>>>
>>>>
>>>>>> Some extra notes that I ran into with not working against
>>>>>> maven-release-plugin.
>>>>>>
>>>>>> The plugin will prompt for the release version, the tag name, and the
>>>>>> next
>>>>>> development version. For 1.5.1, we really want to give 1.5.1,
>>>>>>
>>>>> 1.5.1-rcN,
>>>
>>>> 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in
>>>>>> the
>>>>>> pom which is undesirable.
>>>>>>
>>>>>> To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT
>>>>>> (which
>>>>>> results in the proper values in the pom), created the 1.5.1-rcN branch
>>>>>> from
>>>>>> the release plugin commit for 1.5.1, edited scm.tag in
>>>>>>
>>>>> release.properties
>>>
>>>> to
>>>>>> be 1.5.1-rcN instead of 1.5.1, and then pushed the 1.5.1-rcN branch.
>>>>>> Then,
>>>>>> release:perform will actually build and stage the right code.
>>>>>>
>>>>>> Not as simple as it might be, but at least it works and semi-aligns
>>>>>>
>>>>> with
>>>
>>>> what we described originally.
>>>>>>
>>>>>>
>>>>>> On 1/13/14, 11:16 AM, Josh Elser wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/13/14, 10:17 AM, Mike Drob wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> #1 - No strong opinions.
>>>>>>>> #2 - I want to make the transition for committers from one branch to
>>>>>>>> the
>>>>>>>> next as painless as possible. In particular, I'm worried that
>>>>>>>>
>>>>>>> somebody
>>>
>>>>  will
>>>>>>>> not realize they need to switch branched and accidentally push e.g.
>>>>>>>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really
>>>>>>>>
>>>>>>> really
>>>
>>>>  want just a general 1.4 branch to deal with this case. (And similarly
>>>>>>>> applied to the other lines.)
>>>>>>>>
>>>>>>>> What do you mean "put down the info... with the git-archive?"
>>>>>>>> Listing
>>>>>>>> the
>>>>>>>> exact command?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release
>>>>>>> (candidate)
>>>>>>> shouldn't be harder than ensuring you have a GPG created.
>>>>>>>
>>>>>>>  Another thought I had on this - what kind of tags are we using?
>>>>>>>> Lightweight? Annotated? Signed?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think Christopher had recommended a signed tag. ACCUMULO-1468
>>>>>>> should
>>>>>>> have that definitively, but I'm not really up to date on what
>>>>>>> common/good practices are here.
>>>>>>>
>>>>>>>  I think 1.4.4 has been the only git release, and I used a
>>>>>>>> lightweight
>>>>>>>> tag
>>>>>>>> due to ignorance rather than choice.
>>>>>>>>
>>>>>>>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>  For #1, we typically haven't had a need/desire to keep around how
>>>>>>>>> we
>>>>>>>>> got
>>>>>>>>> to a release (the RCs), but just the final release itself. If this
>>>>>>>>>
>>>>>>>> is
>>>
>>>>  something that has merit to it (besides trying to avoid the same
>>>>>>>>> mistakes
>>>>>>>>> in future releases), I can't think of a good one. Maybe putting an
>>>>>>>>> RC-X
>>>>>>>>> note in the commit message would be sufficient?
>>>>>>>>>
>>>>>>>>> #2, we could. I think the way Mike has this laid out is a little
>>>>>>>>>
>>>>>>>> more
>>>
>>>>  secure against people working already working on things for the next
>>>>>>>>> release (or people who are still working on known bugs in a RC),
>>>>>>>>> but
>>>>>>>>> they
>>>>>>>>> both do the same thing.
>>>>>>>>>
>>>>>>>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to
>>>>>>>>>
>>>>>>>> document
>>>
>>>>  this. Perhaps we can also put down the info you used for 1.4.4 with
>>>>>>>>> the
>>>>>>>>> git-archive? We also should transcribe the mvn-deploy info from
>>>>>>>>> Christopher
>>>>>>>>> that I have linked in the ticket.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>>>>>>>>>
>>>>>>>>>  Overall, the process looks good, and I agree with Josh's
>>>>>>>>>> clarification.
>>>>>>>>>> Two
>>>>>>>>>> pieces of feedback:
>>>>>>>>>>
>>>>>>>>>> 1. Step 8 removes a recording of the history leading to the
>>>>>>>>>>
>>>>>>>>> release.
>>>
>>>>  For
>>>>>>>>>> example, suppose rc1 is no good, and it takes three commits to get
>>>>>>>>>> to rc2,
>>>>>>>>>> which passes. When we remove the rc1 branch, how do we easily
>>>>>>>>>>
>>>>>>>>> figure
>>>
>>>>  out
>>>>>>>>>> months later which commit rc1 had been based on? (Look at an rc1
>>>>>>>>>>
>>>>>>>>> JAR
>>>
>>>>  manifest for the hash? eww.) On the other hand, I can see a benefit
>>>>>>>>>> in
>>>>>>>>>> removing inactive branches and tags to reduce clutter.
>>>>>>>>>>
>>>>>>>>>> 2. We could save a step, namely #7, by applying the increment to
>>>>>>>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
>>>>>>>>>> instead of
>>>>>>>>>> on x.y.z. However, this would not leave a linear history, so I
>>>>>>>>>>
>>>>>>>>> leave
>>>
>>>>  it to
>>>>>>>>>> the more Git-savvy to decide if that is important in this case.
>>>>>>>>>>
>>>>>>>>>> Bill H
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <josh.elser@gmail.com
>>>>>>>>>> >
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>     Looks good to me. I don't think it's too much work in the big
>>>>>>>>>> picture --
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> it's what's necessary to get it done properly given the tool.
>>>>>>>>>>>
>>>>>>>>>>> The only ambiguity I see is in 3a), "make corrections _on
>>>>>>>>>>> x.y.z-SNAPSHOT_".
>>>>>>>>>>>
>>>>>>>>>>> Let's make sure this (assuming there aren't any objections) gets
>>>>>>>>>>>
>>>>>>>>>> up
>>>
>>>>  on
>>>>>>>>>>> the
>>>>>>>>>>> site.
>>>>>>>>>>>
>>>>>>>>>>> - Josh
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>>>>>>>>>
>>>>>>>>>>>     Taking this conversation from IRC because it probably needs
>>>>>>>>>>> to
>>>>>>>>>>>
>>>>>>>>>> be
>>>
>>>>  on the
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> mailing list at some point. Also, we'll want to update the site
>>>>>>>>>>>> when we
>>>>>>>>>>>> have something we are happy with. Thanks to Christopher and Josh
>>>>>>>>>>>> for the
>>>>>>>>>>>> thoughts they've already contributed to the discussion.
>>>>>>>>>>>>
>>>>>>>>>>>> We need a standard procedure for generating RCs that is:
>>>>>>>>>>>> 1) Easily reproducible
>>>>>>>>>>>> 2) Compatible with ongoing development
>>>>>>>>>>>> 3) Compatible with our git branching model.
>>>>>>>>>>>>
>>>>>>>>>>>> The proposed process is:
>>>>>>>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
>>>>>>>>>>>> x.y.z-SNAPSHOT
>>>>>>>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>>>>>>>>>> 3) Perform testing and voting as necessary
>>>>>>>>>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>>>>>>>>>> 4) After a vote passes, tag the release on the same commit that
>>>>>>>>>>>> was the
>>>>>>>>>>>> rc
>>>>>>>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>>>>>>>>>> version)
>>>>>>>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
>>>>>>>>>>>> current
>>>>>>>>>>>> tip
>>>>>>>>>>>> of x.y.z-SNAPSHOT
>>>>>>>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>>>>>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>>>>>>>>>
>>>>>>>>>>>> After having typed that all out it kind of seems like a lot of
>>>>>>>>>>>> steps to
>>>>>>>>>>>> go
>>>>>>>>>>>> through, but on the other hand, we're not going to be doing
>>>>>>>>>>>> everything
>>>>>>>>>>>> at
>>>>>>>>>>>> once anyway.
>>>>>>>>>>>>
>>>>>>>>>>>> Additional feedback would be awesome.
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>

Re: [DISCUSS] How to generate RC's

[Josh Elser <jo...@gmail.com>]

I think I mentioned this earlier/elsewhere already, but I'd prefer 
better communication by parties interesting in testing so that when the 
RC is called, we already have the day+ duration tests already run.

IMO I don't think the voting time is the right time to be trying to find 
"distributed system" level bugs. That should be time focused on judging 
the release itself -- packaging (tarball, rpm, debs, etc), ASF 
requirements (signing, hashes), scripts (init.d, bin/*), basic user 
interaction, and the like.

On 2/11/14, 4:17 PM, Mike Drob wrote:
> One more change that I'd like to see is expanding the voting period beyond
> 72 hours. If I want to test the RC on different hardware/OS/versions than
> the release manager has done, then I need a longer time frame than what is
> currently provided.
>
>
> On Thu, Feb 6, 2014 at 7:54 PM, Christopher <ct...@apache.org> wrote:
>
>> I say don't bump until the vote passes or fails. If it passes, either
>> drop the branch, or if there are commits since the RC was made, no-op
>> merge in the tag, bump the version, and rename the branch. The version
>> doesn't matter until later.
>>
>> I believe the release plugin has a goal to bump versions only, so that
>> part is pretty easy.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Thu, Feb 6, 2014 at 3:49 PM, Josh Elser <jo...@gmail.com> wrote:
>>> Changing the tagNameFormat would remove an extra manual step which is
>> likely
>>> good. I'm not sure about how the local checkout stuff works and if there
>> is
>>> something easier we can do there.
>>>
>>> One extra thing that I've found that is a little awkward to work with now
>>> that we're in a vote, is that we almost want to freeze the 1.5.1-SNAPSHOT
>>> branch. I haven't been able to come up with what we should do with the
>>> branch for the version we're trying to release considering that at least
>> one
>>> RC will probably fail.
>>>
>>> We *could* bump the 1.5.1-SNAPSHOT branch to 1.5.2-SNAPSHOT in the poms,
>> but
>>> then we would need to revert that every time we fail a RC. That's
>> probably
>>> the best solution that doesn't try to work around the
>> maven-release-plugin,
>>> but it does leave some nice blemishes in the history.
>>>
>>>
>>> On 2/5/14, 5:16 PM, Christopher wrote:
>>>>
>>>> We should change tagNameFormat for the maven-release-plugin to
>>>> @{project.version}, so you can just hit "enter" at that field to
>>>> accept the default. You may still need to do the rest of what you did
>>>> (or something similar) to push to a different branch or tag, though...
>>>> I'm not sure (I wonder if you could just let it build the local tag it
>>>> creates instead of editing scm.tag), and simply don't push that tag
>>>> until you change its name to one with -rcX.
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>>
>>>> On Tue, Feb 4, 2014 at 11:50 PM, Josh Elser <jo...@gmail.com>
>> wrote:
>>>>>
>>>>> Some extra notes that I ran into with not working against
>>>>> maven-release-plugin.
>>>>>
>>>>> The plugin will prompt for the release version, the tag name, and the
>>>>> next
>>>>> development version. For 1.5.1, we really want to give 1.5.1,
>> 1.5.1-rcN,
>>>>> 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in
>>>>> the
>>>>> pom which is undesirable.
>>>>>
>>>>> To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT
>>>>> (which
>>>>> results in the proper values in the pom), created the 1.5.1-rcN branch
>>>>> from
>>>>> the release plugin commit for 1.5.1, edited scm.tag in
>> release.properties
>>>>> to
>>>>> be 1.5.1-rcN instead of 1.5.1, and then pushed the 1.5.1-rcN branch.
>>>>> Then,
>>>>> release:perform will actually build and stage the right code.
>>>>>
>>>>> Not as simple as it might be, but at least it works and semi-aligns
>> with
>>>>> what we described originally.
>>>>>
>>>>>
>>>>> On 1/13/14, 11:16 AM, Josh Elser wrote:
>>>>>>
>>>>>>
>>>>>> On 1/13/14, 10:17 AM, Mike Drob wrote:
>>>>>>>
>>>>>>>
>>>>>>> #1 - No strong opinions.
>>>>>>> #2 - I want to make the transition for committers from one branch to
>>>>>>> the
>>>>>>> next as painless as possible. In particular, I'm worried that
>> somebody
>>>>>>> will
>>>>>>> not realize they need to switch branched and accidentally push e.g.
>>>>>>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really
>> really
>>>>>>> want just a general 1.4 branch to deal with this case. (And similarly
>>>>>>> applied to the other lines.)
>>>>>>>
>>>>>>> What do you mean "put down the info... with the git-archive?" Listing
>>>>>>> the
>>>>>>> exact command?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate)
>>>>>> shouldn't be harder than ensuring you have a GPG created.
>>>>>>
>>>>>>> Another thought I had on this - what kind of tags are we using?
>>>>>>> Lightweight? Annotated? Signed?
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think Christopher had recommended a signed tag. ACCUMULO-1468 should
>>>>>> have that definitively, but I'm not really up to date on what
>>>>>> common/good practices are here.
>>>>>>
>>>>>>> I think 1.4.4 has been the only git release, and I used a lightweight
>>>>>>> tag
>>>>>>> due to ignorance rather than choice.
>>>>>>>
>>>>>>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> For #1, we typically haven't had a need/desire to keep around how we
>>>>>>>> got
>>>>>>>> to a release (the RCs), but just the final release itself. If this
>> is
>>>>>>>> something that has merit to it (besides trying to avoid the same
>>>>>>>> mistakes
>>>>>>>> in future releases), I can't think of a good one. Maybe putting an
>>>>>>>> RC-X
>>>>>>>> note in the commit message would be sufficient?
>>>>>>>>
>>>>>>>> #2, we could. I think the way Mike has this laid out is a little
>> more
>>>>>>>> secure against people working already working on things for the next
>>>>>>>> release (or people who are still working on known bugs in a RC), but
>>>>>>>> they
>>>>>>>> both do the same thing.
>>>>>>>>
>>>>>>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to
>> document
>>>>>>>> this. Perhaps we can also put down the info you used for 1.4.4 with
>>>>>>>> the
>>>>>>>> git-archive? We also should transcribe the mvn-deploy info from
>>>>>>>> Christopher
>>>>>>>> that I have linked in the ticket.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>>>>>>>>
>>>>>>>>> Overall, the process looks good, and I agree with Josh's
>>>>>>>>> clarification.
>>>>>>>>> Two
>>>>>>>>> pieces of feedback:
>>>>>>>>>
>>>>>>>>> 1. Step 8 removes a recording of the history leading to the
>> release.
>>>>>>>>> For
>>>>>>>>> example, suppose rc1 is no good, and it takes three commits to get
>>>>>>>>> to rc2,
>>>>>>>>> which passes. When we remove the rc1 branch, how do we easily
>> figure
>>>>>>>>> out
>>>>>>>>> months later which commit rc1 had been based on? (Look at an rc1
>> JAR
>>>>>>>>> manifest for the hash? eww.) On the other hand, I can see a benefit
>>>>>>>>> in
>>>>>>>>> removing inactive branches and tags to reduce clutter.
>>>>>>>>>
>>>>>>>>> 2. We could save a step, namely #7, by applying the increment to
>>>>>>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
>>>>>>>>> instead of
>>>>>>>>> on x.y.z. However, this would not leave a linear history, so I
>> leave
>>>>>>>>> it to
>>>>>>>>> the more Git-savvy to decide if that is important in this case.
>>>>>>>>>
>>>>>>>>> Bill H
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>     Looks good to me. I don't think it's too much work in the big
>>>>>>>>> picture --
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> it's what's necessary to get it done properly given the tool.
>>>>>>>>>>
>>>>>>>>>> The only ambiguity I see is in 3a), "make corrections _on
>>>>>>>>>> x.y.z-SNAPSHOT_".
>>>>>>>>>>
>>>>>>>>>> Let's make sure this (assuming there aren't any objections) gets
>> up
>>>>>>>>>> on
>>>>>>>>>> the
>>>>>>>>>> site.
>>>>>>>>>>
>>>>>>>>>> - Josh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>>>>>>>>
>>>>>>>>>>     Taking this conversation from IRC because it probably needs to
>> be
>>>>>>>>>> on the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> mailing list at some point. Also, we'll want to update the site
>>>>>>>>>>> when we
>>>>>>>>>>> have something we are happy with. Thanks to Christopher and Josh
>>>>>>>>>>> for the
>>>>>>>>>>> thoughts they've already contributed to the discussion.
>>>>>>>>>>>
>>>>>>>>>>> We need a standard procedure for generating RCs that is:
>>>>>>>>>>> 1) Easily reproducible
>>>>>>>>>>> 2) Compatible with ongoing development
>>>>>>>>>>> 3) Compatible with our git branching model.
>>>>>>>>>>>
>>>>>>>>>>> The proposed process is:
>>>>>>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
>>>>>>>>>>> x.y.z-SNAPSHOT
>>>>>>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>>>>>>>>> 3) Perform testing and voting as necessary
>>>>>>>>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>>>>>>>>> 4) After a vote passes, tag the release on the same commit that
>>>>>>>>>>> was the
>>>>>>>>>>> rc
>>>>>>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>>>>>>>>> version)
>>>>>>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
>>>>>>>>>>> current
>>>>>>>>>>> tip
>>>>>>>>>>> of x.y.z-SNAPSHOT
>>>>>>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>>>>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>>>>>>>>
>>>>>>>>>>> After having typed that all out it kind of seems like a lot of
>>>>>>>>>>> steps to
>>>>>>>>>>> go
>>>>>>>>>>> through, but on the other hand, we're not going to be doing
>>>>>>>>>>> everything
>>>>>>>>>>> at
>>>>>>>>>>> once anyway.
>>>>>>>>>>>
>>>>>>>>>>> Additional feedback would be awesome.
>>>>>>>>>>>
>>>>>>>>>>> Mike
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

Re: [DISCUSS] How to generate RC's

[Mike Drob <ma...@cloudera.com>]

One more change that I'd like to see is expanding the voting period beyond
72 hours. If I want to test the RC on different hardware/OS/versions than
the release manager has done, then I need a longer time frame than what is
currently provided.


On Thu, Feb 6, 2014 at 7:54 PM, Christopher <ct...@apache.org> wrote:

> I say don't bump until the vote passes or fails. If it passes, either
> drop the branch, or if there are commits since the RC was made, no-op
> merge in the tag, bump the version, and rename the branch. The version
> doesn't matter until later.
>
> I believe the release plugin has a goal to bump versions only, so that
> part is pretty easy.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Thu, Feb 6, 2014 at 3:49 PM, Josh Elser <jo...@gmail.com> wrote:
> > Changing the tagNameFormat would remove an extra manual step which is
> likely
> > good. I'm not sure about how the local checkout stuff works and if there
> is
> > something easier we can do there.
> >
> > One extra thing that I've found that is a little awkward to work with now
> > that we're in a vote, is that we almost want to freeze the 1.5.1-SNAPSHOT
> > branch. I haven't been able to come up with what we should do with the
> > branch for the version we're trying to release considering that at least
> one
> > RC will probably fail.
> >
> > We *could* bump the 1.5.1-SNAPSHOT branch to 1.5.2-SNAPSHOT in the poms,
> but
> > then we would need to revert that every time we fail a RC. That's
> probably
> > the best solution that doesn't try to work around the
> maven-release-plugin,
> > but it does leave some nice blemishes in the history.
> >
> >
> > On 2/5/14, 5:16 PM, Christopher wrote:
> >>
> >> We should change tagNameFormat for the maven-release-plugin to
> >> @{project.version}, so you can just hit "enter" at that field to
> >> accept the default. You may still need to do the rest of what you did
> >> (or something similar) to push to a different branch or tag, though...
> >> I'm not sure (I wonder if you could just let it build the local tag it
> >> creates instead of editing scm.tag), and simply don't push that tag
> >> until you change its name to one with -rcX.
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >>
> >> On Tue, Feb 4, 2014 at 11:50 PM, Josh Elser <jo...@gmail.com>
> wrote:
> >>>
> >>> Some extra notes that I ran into with not working against
> >>> maven-release-plugin.
> >>>
> >>> The plugin will prompt for the release version, the tag name, and the
> >>> next
> >>> development version. For 1.5.1, we really want to give 1.5.1,
> 1.5.1-rcN,
> >>> 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in
> >>> the
> >>> pom which is undesirable.
> >>>
> >>> To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT
> >>> (which
> >>> results in the proper values in the pom), created the 1.5.1-rcN branch
> >>> from
> >>> the release plugin commit for 1.5.1, edited scm.tag in
> release.properties
> >>> to
> >>> be 1.5.1-rcN instead of 1.5.1, and then pushed the 1.5.1-rcN branch.
> >>> Then,
> >>> release:perform will actually build and stage the right code.
> >>>
> >>> Not as simple as it might be, but at least it works and semi-aligns
> with
> >>> what we described originally.
> >>>
> >>>
> >>> On 1/13/14, 11:16 AM, Josh Elser wrote:
> >>>>
> >>>>
> >>>> On 1/13/14, 10:17 AM, Mike Drob wrote:
> >>>>>
> >>>>>
> >>>>> #1 - No strong opinions.
> >>>>> #2 - I want to make the transition for committers from one branch to
> >>>>> the
> >>>>> next as painless as possible. In particular, I'm worried that
> somebody
> >>>>> will
> >>>>> not realize they need to switch branched and accidentally push e.g.
> >>>>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really
> really
> >>>>> want just a general 1.4 branch to deal with this case. (And similarly
> >>>>> applied to the other lines.)
> >>>>>
> >>>>> What do you mean "put down the info... with the git-archive?" Listing
> >>>>> the
> >>>>> exact command?
> >>>>
> >>>>
> >>>>
> >>>> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate)
> >>>> shouldn't be harder than ensuring you have a GPG created.
> >>>>
> >>>>> Another thought I had on this - what kind of tags are we using?
> >>>>> Lightweight? Annotated? Signed?
> >>>>
> >>>>
> >>>>
> >>>> I think Christopher had recommended a signed tag. ACCUMULO-1468 should
> >>>> have that definitively, but I'm not really up to date on what
> >>>> common/good practices are here.
> >>>>
> >>>>> I think 1.4.4 has been the only git release, and I used a lightweight
> >>>>> tag
> >>>>> due to ignorance rather than choice.
> >>>>>
> >>>>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> For #1, we typically haven't had a need/desire to keep around how we
> >>>>>> got
> >>>>>> to a release (the RCs), but just the final release itself. If this
> is
> >>>>>> something that has merit to it (besides trying to avoid the same
> >>>>>> mistakes
> >>>>>> in future releases), I can't think of a good one. Maybe putting an
> >>>>>> RC-X
> >>>>>> note in the commit message would be sufficient?
> >>>>>>
> >>>>>> #2, we could. I think the way Mike has this laid out is a little
> more
> >>>>>> secure against people working already working on things for the next
> >>>>>> release (or people who are still working on known bugs in a RC), but
> >>>>>> they
> >>>>>> both do the same thing.
> >>>>>>
> >>>>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to
> document
> >>>>>> this. Perhaps we can also put down the info you used for 1.4.4 with
> >>>>>> the
> >>>>>> git-archive? We also should transcribe the mvn-deploy info from
> >>>>>> Christopher
> >>>>>> that I have linked in the ticket.
> >>>>>>
> >>>>>>
> >>>>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
> >>>>>>
> >>>>>>> Overall, the process looks good, and I agree with Josh's
> >>>>>>> clarification.
> >>>>>>> Two
> >>>>>>> pieces of feedback:
> >>>>>>>
> >>>>>>> 1. Step 8 removes a recording of the history leading to the
> release.
> >>>>>>> For
> >>>>>>> example, suppose rc1 is no good, and it takes three commits to get
> >>>>>>> to rc2,
> >>>>>>> which passes. When we remove the rc1 branch, how do we easily
> figure
> >>>>>>> out
> >>>>>>> months later which commit rc1 had been based on? (Look at an rc1
> JAR
> >>>>>>> manifest for the hash? eww.) On the other hand, I can see a benefit
> >>>>>>> in
> >>>>>>> removing inactive branches and tags to reduce clutter.
> >>>>>>>
> >>>>>>> 2. We could save a step, namely #7, by applying the increment to
> >>>>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
> >>>>>>> instead of
> >>>>>>> on x.y.z. However, this would not leave a linear history, so I
> leave
> >>>>>>> it to
> >>>>>>> the more Git-savvy to decide if that is important in this case.
> >>>>>>>
> >>>>>>> Bill H
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>    Looks good to me. I don't think it's too much work in the big
> >>>>>>> picture --
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> it's what's necessary to get it done properly given the tool.
> >>>>>>>>
> >>>>>>>> The only ambiguity I see is in 3a), "make corrections _on
> >>>>>>>> x.y.z-SNAPSHOT_".
> >>>>>>>>
> >>>>>>>> Let's make sure this (assuming there aren't any objections) gets
> up
> >>>>>>>> on
> >>>>>>>> the
> >>>>>>>> site.
> >>>>>>>>
> >>>>>>>> - Josh
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
> >>>>>>>>
> >>>>>>>>    Taking this conversation from IRC because it probably needs to
> be
> >>>>>>>> on the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> mailing list at some point. Also, we'll want to update the site
> >>>>>>>>> when we
> >>>>>>>>> have something we are happy with. Thanks to Christopher and Josh
> >>>>>>>>> for the
> >>>>>>>>> thoughts they've already contributed to the discussion.
> >>>>>>>>>
> >>>>>>>>> We need a standard procedure for generating RCs that is:
> >>>>>>>>> 1) Easily reproducible
> >>>>>>>>> 2) Compatible with ongoing development
> >>>>>>>>> 3) Compatible with our git branching model.
> >>>>>>>>>
> >>>>>>>>> The proposed process is:
> >>>>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
> >>>>>>>>> x.y.z-SNAPSHOT
> >>>>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
> >>>>>>>>> 3) Perform testing and voting as necessary
> >>>>>>>>> 3a) If the vote fails, make corrections and start over at 1)
> >>>>>>>>> 4) After a vote passes, tag the release on the same commit that
> >>>>>>>>> was the
> >>>>>>>>> rc
> >>>>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
> >>>>>>>>> version)
> >>>>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
> >>>>>>>>> current
> >>>>>>>>> tip
> >>>>>>>>> of x.y.z-SNAPSHOT
> >>>>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
> >>>>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
> >>>>>>>>>
> >>>>>>>>> After having typed that all out it kind of seems like a lot of
> >>>>>>>>> steps to
> >>>>>>>>> go
> >>>>>>>>> through, but on the other hand, we're not going to be doing
> >>>>>>>>> everything
> >>>>>>>>> at
> >>>>>>>>> once anyway.
> >>>>>>>>>
> >>>>>>>>> Additional feedback would be awesome.
> >>>>>>>>>
> >>>>>>>>> Mike
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
>

Re: [DISCUSS] How to generate RC's

[Christopher <ct...@apache.org>]

I say don't bump until the vote passes or fails. If it passes, either
drop the branch, or if there are commits since the RC was made, no-op
merge in the tag, bump the version, and rename the branch. The version
doesn't matter until later.

I believe the release plugin has a goal to bump versions only, so that
part is pretty easy.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Thu, Feb 6, 2014 at 3:49 PM, Josh Elser <jo...@gmail.com> wrote:
> Changing the tagNameFormat would remove an extra manual step which is likely
> good. I'm not sure about how the local checkout stuff works and if there is
> something easier we can do there.
>
> One extra thing that I've found that is a little awkward to work with now
> that we're in a vote, is that we almost want to freeze the 1.5.1-SNAPSHOT
> branch. I haven't been able to come up with what we should do with the
> branch for the version we're trying to release considering that at least one
> RC will probably fail.
>
> We *could* bump the 1.5.1-SNAPSHOT branch to 1.5.2-SNAPSHOT in the poms, but
> then we would need to revert that every time we fail a RC. That's probably
> the best solution that doesn't try to work around the maven-release-plugin,
> but it does leave some nice blemishes in the history.
>
>
> On 2/5/14, 5:16 PM, Christopher wrote:
>>
>> We should change tagNameFormat for the maven-release-plugin to
>> @{project.version}, so you can just hit "enter" at that field to
>> accept the default. You may still need to do the rest of what you did
>> (or something similar) to push to a different branch or tag, though...
>> I'm not sure (I wonder if you could just let it build the local tag it
>> creates instead of editing scm.tag), and simply don't push that tag
>> until you change its name to one with -rcX.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Tue, Feb 4, 2014 at 11:50 PM, Josh Elser <jo...@gmail.com> wrote:
>>>
>>> Some extra notes that I ran into with not working against
>>> maven-release-plugin.
>>>
>>> The plugin will prompt for the release version, the tag name, and the
>>> next
>>> development version. For 1.5.1, we really want to give 1.5.1, 1.5.1-rcN,
>>> 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in
>>> the
>>> pom which is undesirable.
>>>
>>> To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT
>>> (which
>>> results in the proper values in the pom), created the 1.5.1-rcN branch
>>> from
>>> the release plugin commit for 1.5.1, edited scm.tag in release.properties
>>> to
>>> be 1.5.1-rcN instead of 1.5.1, and then pushed the 1.5.1-rcN branch.
>>> Then,
>>> release:perform will actually build and stage the right code.
>>>
>>> Not as simple as it might be, but at least it works and semi-aligns with
>>> what we described originally.
>>>
>>>
>>> On 1/13/14, 11:16 AM, Josh Elser wrote:
>>>>
>>>>
>>>> On 1/13/14, 10:17 AM, Mike Drob wrote:
>>>>>
>>>>>
>>>>> #1 - No strong opinions.
>>>>> #2 - I want to make the transition for committers from one branch to
>>>>> the
>>>>> next as painless as possible. In particular, I'm worried that somebody
>>>>> will
>>>>> not realize they need to switch branched and accidentally push e.g.
>>>>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
>>>>> want just a general 1.4 branch to deal with this case. (And similarly
>>>>> applied to the other lines.)
>>>>>
>>>>> What do you mean "put down the info... with the git-archive?" Listing
>>>>> the
>>>>> exact command?
>>>>
>>>>
>>>>
>>>> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate)
>>>> shouldn't be harder than ensuring you have a GPG created.
>>>>
>>>>> Another thought I had on this - what kind of tags are we using?
>>>>> Lightweight? Annotated? Signed?
>>>>
>>>>
>>>>
>>>> I think Christopher had recommended a signed tag. ACCUMULO-1468 should
>>>> have that definitively, but I'm not really up to date on what
>>>> common/good practices are here.
>>>>
>>>>> I think 1.4.4 has been the only git release, and I used a lightweight
>>>>> tag
>>>>> due to ignorance rather than choice.
>>>>>
>>>>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> For #1, we typically haven't had a need/desire to keep around how we
>>>>>> got
>>>>>> to a release (the RCs), but just the final release itself. If this is
>>>>>> something that has merit to it (besides trying to avoid the same
>>>>>> mistakes
>>>>>> in future releases), I can't think of a good one. Maybe putting an
>>>>>> RC-X
>>>>>> note in the commit message would be sufficient?
>>>>>>
>>>>>> #2, we could. I think the way Mike has this laid out is a little more
>>>>>> secure against people working already working on things for the next
>>>>>> release (or people who are still working on known bugs in a RC), but
>>>>>> they
>>>>>> both do the same thing.
>>>>>>
>>>>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document
>>>>>> this. Perhaps we can also put down the info you used for 1.4.4 with
>>>>>> the
>>>>>> git-archive? We also should transcribe the mvn-deploy info from
>>>>>> Christopher
>>>>>> that I have linked in the ticket.
>>>>>>
>>>>>>
>>>>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>>>>>>
>>>>>>> Overall, the process looks good, and I agree with Josh's
>>>>>>> clarification.
>>>>>>> Two
>>>>>>> pieces of feedback:
>>>>>>>
>>>>>>> 1. Step 8 removes a recording of the history leading to the release.
>>>>>>> For
>>>>>>> example, suppose rc1 is no good, and it takes three commits to get
>>>>>>> to rc2,
>>>>>>> which passes. When we remove the rc1 branch, how do we easily figure
>>>>>>> out
>>>>>>> months later which commit rc1 had been based on? (Look at an rc1 JAR
>>>>>>> manifest for the hash? eww.) On the other hand, I can see a benefit
>>>>>>> in
>>>>>>> removing inactive branches and tags to reduce clutter.
>>>>>>>
>>>>>>> 2. We could save a step, namely #7, by applying the increment to
>>>>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
>>>>>>> instead of
>>>>>>> on x.y.z. However, this would not leave a linear history, so I leave
>>>>>>> it to
>>>>>>> the more Git-savvy to decide if that is important in this case.
>>>>>>>
>>>>>>> Bill H
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>    Looks good to me. I don't think it's too much work in the big
>>>>>>> picture --
>>>>>>>>
>>>>>>>>
>>>>>>>> it's what's necessary to get it done properly given the tool.
>>>>>>>>
>>>>>>>> The only ambiguity I see is in 3a), "make corrections _on
>>>>>>>> x.y.z-SNAPSHOT_".
>>>>>>>>
>>>>>>>> Let's make sure this (assuming there aren't any objections) gets up
>>>>>>>> on
>>>>>>>> the
>>>>>>>> site.
>>>>>>>>
>>>>>>>> - Josh
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>>>>>>
>>>>>>>>    Taking this conversation from IRC because it probably needs to be
>>>>>>>> on the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> mailing list at some point. Also, we'll want to update the site
>>>>>>>>> when we
>>>>>>>>> have something we are happy with. Thanks to Christopher and Josh
>>>>>>>>> for the
>>>>>>>>> thoughts they've already contributed to the discussion.
>>>>>>>>>
>>>>>>>>> We need a standard procedure for generating RCs that is:
>>>>>>>>> 1) Easily reproducible
>>>>>>>>> 2) Compatible with ongoing development
>>>>>>>>> 3) Compatible with our git branching model.
>>>>>>>>>
>>>>>>>>> The proposed process is:
>>>>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
>>>>>>>>> x.y.z-SNAPSHOT
>>>>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>>>>>>> 3) Perform testing and voting as necessary
>>>>>>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>>>>>>> 4) After a vote passes, tag the release on the same commit that
>>>>>>>>> was the
>>>>>>>>> rc
>>>>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>>>>>>> version)
>>>>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
>>>>>>>>> current
>>>>>>>>> tip
>>>>>>>>> of x.y.z-SNAPSHOT
>>>>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>>>>>>
>>>>>>>>> After having typed that all out it kind of seems like a lot of
>>>>>>>>> steps to
>>>>>>>>> go
>>>>>>>>> through, but on the other hand, we're not going to be doing
>>>>>>>>> everything
>>>>>>>>> at
>>>>>>>>> once anyway.
>>>>>>>>>
>>>>>>>>> Additional feedback would be awesome.
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>

Re: [DISCUSS] How to generate RC's

[Josh Elser <jo...@gmail.com>]

Changing the tagNameFormat would remove an extra manual step which is 
likely good. I'm not sure about how the local checkout stuff works and 
if there is something easier we can do there.

One extra thing that I've found that is a little awkward to work with 
now that we're in a vote, is that we almost want to freeze the 
1.5.1-SNAPSHOT branch. I haven't been able to come up with what we 
should do with the branch for the version we're trying to release 
considering that at least one RC will probably fail.

We *could* bump the 1.5.1-SNAPSHOT branch to 1.5.2-SNAPSHOT in the poms, 
but then we would need to revert that every time we fail a RC. That's 
probably the best solution that doesn't try to work around the 
maven-release-plugin, but it does leave some nice blemishes in the history.

On 2/5/14, 5:16 PM, Christopher wrote:
> We should change tagNameFormat for the maven-release-plugin to
> @{project.version}, so you can just hit "enter" at that field to
> accept the default. You may still need to do the rest of what you did
> (or something similar) to push to a different branch or tag, though...
> I'm not sure (I wonder if you could just let it build the local tag it
> creates instead of editing scm.tag), and simply don't push that tag
> until you change its name to one with -rcX.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Feb 4, 2014 at 11:50 PM, Josh Elser <jo...@gmail.com> wrote:
>> Some extra notes that I ran into with not working against
>> maven-release-plugin.
>>
>> The plugin will prompt for the release version, the tag name, and the next
>> development version. For 1.5.1, we really want to give 1.5.1, 1.5.1-rcN,
>> 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in the
>> pom which is undesirable.
>>
>> To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT (which
>> results in the proper values in the pom), created the 1.5.1-rcN branch from
>> the release plugin commit for 1.5.1, edited scm.tag in release.properties to
>> be 1.5.1-rcN instead of 1.5.1, and then pushed the 1.5.1-rcN branch. Then,
>> release:perform will actually build and stage the right code.
>>
>> Not as simple as it might be, but at least it works and semi-aligns with
>> what we described originally.
>>
>>
>> On 1/13/14, 11:16 AM, Josh Elser wrote:
>>>
>>> On 1/13/14, 10:17 AM, Mike Drob wrote:
>>>>
>>>> #1 - No strong opinions.
>>>> #2 - I want to make the transition for committers from one branch to the
>>>> next as painless as possible. In particular, I'm worried that somebody
>>>> will
>>>> not realize they need to switch branched and accidentally push e.g.
>>>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
>>>> want just a general 1.4 branch to deal with this case. (And similarly
>>>> applied to the other lines.)
>>>>
>>>> What do you mean "put down the info... with the git-archive?" Listing the
>>>> exact command?
>>>
>>>
>>> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate)
>>> shouldn't be harder than ensuring you have a GPG created.
>>>
>>>> Another thought I had on this - what kind of tags are we using?
>>>> Lightweight? Annotated? Signed?
>>>
>>>
>>> I think Christopher had recommended a signed tag. ACCUMULO-1468 should
>>> have that definitively, but I'm not really up to date on what
>>> common/good practices are here.
>>>
>>>> I think 1.4.4 has been the only git release, and I used a lightweight tag
>>>> due to ignorance rather than choice.
>>>>
>>>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
>>>> wrote:
>>>>
>>>>> For #1, we typically haven't had a need/desire to keep around how we got
>>>>> to a release (the RCs), but just the final release itself. If this is
>>>>> something that has merit to it (besides trying to avoid the same
>>>>> mistakes
>>>>> in future releases), I can't think of a good one. Maybe putting an RC-X
>>>>> note in the commit message would be sufficient?
>>>>>
>>>>> #2, we could. I think the way Mike has this laid out is a little more
>>>>> secure against people working already working on things for the next
>>>>> release (or people who are still working on known bugs in a RC), but
>>>>> they
>>>>> both do the same thing.
>>>>>
>>>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document
>>>>> this. Perhaps we can also put down the info you used for 1.4.4 with the
>>>>> git-archive? We also should transcribe the mvn-deploy info from
>>>>> Christopher
>>>>> that I have linked in the ticket.
>>>>>
>>>>>
>>>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>>>>>
>>>>>> Overall, the process looks good, and I agree with Josh's clarification.
>>>>>> Two
>>>>>> pieces of feedback:
>>>>>>
>>>>>> 1. Step 8 removes a recording of the history leading to the release.
>>>>>> For
>>>>>> example, suppose rc1 is no good, and it takes three commits to get
>>>>>> to rc2,
>>>>>> which passes. When we remove the rc1 branch, how do we easily figure
>>>>>> out
>>>>>> months later which commit rc1 had been based on? (Look at an rc1 JAR
>>>>>> manifest for the hash? eww.) On the other hand, I can see a benefit in
>>>>>> removing inactive branches and tags to reduce clutter.
>>>>>>
>>>>>> 2. We could save a step, namely #7, by applying the increment to
>>>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
>>>>>> instead of
>>>>>> on x.y.z. However, this would not leave a linear history, so I leave
>>>>>> it to
>>>>>> the more Git-savvy to decide if that is important in this case.
>>>>>>
>>>>>> Bill H
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>    Looks good to me. I don't think it's too much work in the big
>>>>>> picture --
>>>>>>>
>>>>>>> it's what's necessary to get it done properly given the tool.
>>>>>>>
>>>>>>> The only ambiguity I see is in 3a), "make corrections _on
>>>>>>> x.y.z-SNAPSHOT_".
>>>>>>>
>>>>>>> Let's make sure this (assuming there aren't any objections) gets up on
>>>>>>> the
>>>>>>> site.
>>>>>>>
>>>>>>> - Josh
>>>>>>>
>>>>>>>
>>>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>>>>>
>>>>>>>    Taking this conversation from IRC because it probably needs to be
>>>>>>> on the
>>>>>>>>
>>>>>>>> mailing list at some point. Also, we'll want to update the site
>>>>>>>> when we
>>>>>>>> have something we are happy with. Thanks to Christopher and Josh
>>>>>>>> for the
>>>>>>>> thoughts they've already contributed to the discussion.
>>>>>>>>
>>>>>>>> We need a standard procedure for generating RCs that is:
>>>>>>>> 1) Easily reproducible
>>>>>>>> 2) Compatible with ongoing development
>>>>>>>> 3) Compatible with our git branching model.
>>>>>>>>
>>>>>>>> The proposed process is:
>>>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
>>>>>>>> x.y.z-SNAPSHOT
>>>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>>>>>> 3) Perform testing and voting as necessary
>>>>>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>>>>>> 4) After a vote passes, tag the release on the same commit that
>>>>>>>> was the
>>>>>>>> rc
>>>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>>>>>> version)
>>>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
>>>>>>>> current
>>>>>>>> tip
>>>>>>>> of x.y.z-SNAPSHOT
>>>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>>>>>
>>>>>>>> After having typed that all out it kind of seems like a lot of
>>>>>>>> steps to
>>>>>>>> go
>>>>>>>> through, but on the other hand, we're not going to be doing
>>>>>>>> everything
>>>>>>>> at
>>>>>>>> once anyway.
>>>>>>>>
>>>>>>>> Additional feedback would be awesome.
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>

Re: [DISCUSS] How to generate RC's

[Christopher <ct...@apache.org>]

We should change tagNameFormat for the maven-release-plugin to
@{project.version}, so you can just hit "enter" at that field to
accept the default. You may still need to do the rest of what you did
(or something similar) to push to a different branch or tag, though...
I'm not sure (I wonder if you could just let it build the local tag it
creates instead of editing scm.tag), and simply don't push that tag
until you change its name to one with -rcX.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Tue, Feb 4, 2014 at 11:50 PM, Josh Elser <jo...@gmail.com> wrote:
> Some extra notes that I ran into with not working against
> maven-release-plugin.
>
> The plugin will prompt for the release version, the tag name, and the next
> development version. For 1.5.1, we really want to give 1.5.1, 1.5.1-rcN,
> 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in the
> pom which is undesirable.
>
> To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT (which
> results in the proper values in the pom), created the 1.5.1-rcN branch from
> the release plugin commit for 1.5.1, edited scm.tag in release.properties to
> be 1.5.1-rcN instead of 1.5.1, and then pushed the 1.5.1-rcN branch. Then,
> release:perform will actually build and stage the right code.
>
> Not as simple as it might be, but at least it works and semi-aligns with
> what we described originally.
>
>
> On 1/13/14, 11:16 AM, Josh Elser wrote:
>>
>> On 1/13/14, 10:17 AM, Mike Drob wrote:
>>>
>>> #1 - No strong opinions.
>>> #2 - I want to make the transition for committers from one branch to the
>>> next as painless as possible. In particular, I'm worried that somebody
>>> will
>>> not realize they need to switch branched and accidentally push e.g.
>>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
>>> want just a general 1.4 branch to deal with this case. (And similarly
>>> applied to the other lines.)
>>>
>>> What do you mean "put down the info... with the git-archive?" Listing the
>>> exact command?
>>
>>
>> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate)
>> shouldn't be harder than ensuring you have a GPG created.
>>
>>> Another thought I had on this - what kind of tags are we using?
>>> Lightweight? Annotated? Signed?
>>
>>
>> I think Christopher had recommended a signed tag. ACCUMULO-1468 should
>> have that definitively, but I'm not really up to date on what
>> common/good practices are here.
>>
>>> I think 1.4.4 has been the only git release, and I used a lightweight tag
>>> due to ignorance rather than choice.
>>>
>>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
>>> wrote:
>>>
>>>> For #1, we typically haven't had a need/desire to keep around how we got
>>>> to a release (the RCs), but just the final release itself. If this is
>>>> something that has merit to it (besides trying to avoid the same
>>>> mistakes
>>>> in future releases), I can't think of a good one. Maybe putting an RC-X
>>>> note in the commit message would be sufficient?
>>>>
>>>> #2, we could. I think the way Mike has this laid out is a little more
>>>> secure against people working already working on things for the next
>>>> release (or people who are still working on known bugs in a RC), but
>>>> they
>>>> both do the same thing.
>>>>
>>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document
>>>> this. Perhaps we can also put down the info you used for 1.4.4 with the
>>>> git-archive? We also should transcribe the mvn-deploy info from
>>>> Christopher
>>>> that I have linked in the ticket.
>>>>
>>>>
>>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>>>>
>>>>> Overall, the process looks good, and I agree with Josh's clarification.
>>>>> Two
>>>>> pieces of feedback:
>>>>>
>>>>> 1. Step 8 removes a recording of the history leading to the release.
>>>>> For
>>>>> example, suppose rc1 is no good, and it takes three commits to get
>>>>> to rc2,
>>>>> which passes. When we remove the rc1 branch, how do we easily figure
>>>>> out
>>>>> months later which commit rc1 had been based on? (Look at an rc1 JAR
>>>>> manifest for the hash? eww.) On the other hand, I can see a benefit in
>>>>> removing inactive branches and tags to reduce clutter.
>>>>>
>>>>> 2. We could save a step, namely #7, by applying the increment to
>>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
>>>>> instead of
>>>>> on x.y.z. However, this would not leave a linear history, so I leave
>>>>> it to
>>>>> the more Git-savvy to decide if that is important in this case.
>>>>>
>>>>> Bill H
>>>>>
>>>>>
>>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>   Looks good to me. I don't think it's too much work in the big
>>>>> picture --
>>>>>>
>>>>>> it's what's necessary to get it done properly given the tool.
>>>>>>
>>>>>> The only ambiguity I see is in 3a), "make corrections _on
>>>>>> x.y.z-SNAPSHOT_".
>>>>>>
>>>>>> Let's make sure this (assuming there aren't any objections) gets up on
>>>>>> the
>>>>>> site.
>>>>>>
>>>>>> - Josh
>>>>>>
>>>>>>
>>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>>>>
>>>>>>   Taking this conversation from IRC because it probably needs to be
>>>>>> on the
>>>>>>>
>>>>>>> mailing list at some point. Also, we'll want to update the site
>>>>>>> when we
>>>>>>> have something we are happy with. Thanks to Christopher and Josh
>>>>>>> for the
>>>>>>> thoughts they've already contributed to the discussion.
>>>>>>>
>>>>>>> We need a standard procedure for generating RCs that is:
>>>>>>> 1) Easily reproducible
>>>>>>> 2) Compatible with ongoing development
>>>>>>> 3) Compatible with our git branching model.
>>>>>>>
>>>>>>> The proposed process is:
>>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
>>>>>>> x.y.z-SNAPSHOT
>>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>>>>> 3) Perform testing and voting as necessary
>>>>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>>>>> 4) After a vote passes, tag the release on the same commit that
>>>>>>> was the
>>>>>>> rc
>>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>>>>> version)
>>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
>>>>>>> current
>>>>>>> tip
>>>>>>> of x.y.z-SNAPSHOT
>>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>>>>
>>>>>>> After having typed that all out it kind of seems like a lot of
>>>>>>> steps to
>>>>>>> go
>>>>>>> through, but on the other hand, we're not going to be doing
>>>>>>> everything
>>>>>>> at
>>>>>>> once anyway.
>>>>>>>
>>>>>>> Additional feedback would be awesome.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>

Re: [DISCUSS] How to generate RC's

[Josh Elser <jo...@gmail.com>]

Some extra notes that I ran into with not working against 
maven-release-plugin.

The plugin will prompt for the release version, the tag name, and the 
next development version. For 1.5.1, we really want to give 1.5.1, 
1.5.1-rcN, 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being 
placed in the pom which is undesirable.

To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT 
(which results in the proper values in the pom), created the 1.5.1-rcN 
branch from the release plugin commit for 1.5.1, edited scm.tag in 
release.properties to be 1.5.1-rcN instead of 1.5.1, and then pushed the 
1.5.1-rcN branch. Then, release:perform will actually build and stage 
the right code.

Not as simple as it might be, but at least it works and semi-aligns with 
what we described originally.

On 1/13/14, 11:16 AM, Josh Elser wrote:
> On 1/13/14, 10:17 AM, Mike Drob wrote:
>> #1 - No strong opinions.
>> #2 - I want to make the transition for committers from one branch to the
>> next as painless as possible. In particular, I'm worried that somebody
>> will
>> not realize they need to switch branched and accidentally push e.g.
>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
>> want just a general 1.4 branch to deal with this case. (And similarly
>> applied to the other lines.)
>>
>> What do you mean "put down the info... with the git-archive?" Listing the
>> exact command?
>
> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate)
> shouldn't be harder than ensuring you have a GPG created.
>
>> Another thought I had on this - what kind of tags are we using?
>> Lightweight? Annotated? Signed?
>
> I think Christopher had recommended a signed tag. ACCUMULO-1468 should
> have that definitively, but I'm not really up to date on what
> common/good practices are here.
>
>> I think 1.4.4 has been the only git release, and I used a lightweight tag
>> due to ignorance rather than choice.
>>
>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com>
>> wrote:
>>
>>> For #1, we typically haven't had a need/desire to keep around how we got
>>> to a release (the RCs), but just the final release itself. If this is
>>> something that has merit to it (besides trying to avoid the same
>>> mistakes
>>> in future releases), I can't think of a good one. Maybe putting an RC-X
>>> note in the commit message would be sufficient?
>>>
>>> #2, we could. I think the way Mike has this laid out is a little more
>>> secure against people working already working on things for the next
>>> release (or people who are still working on known bugs in a RC), but
>>> they
>>> both do the same thing.
>>>
>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document
>>> this. Perhaps we can also put down the info you used for 1.4.4 with the
>>> git-archive? We also should transcribe the mvn-deploy info from
>>> Christopher
>>> that I have linked in the ticket.
>>>
>>>
>>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>>>
>>>> Overall, the process looks good, and I agree with Josh's clarification.
>>>> Two
>>>> pieces of feedback:
>>>>
>>>> 1. Step 8 removes a recording of the history leading to the release.
>>>> For
>>>> example, suppose rc1 is no good, and it takes three commits to get
>>>> to rc2,
>>>> which passes. When we remove the rc1 branch, how do we easily figure
>>>> out
>>>> months later which commit rc1 had been based on? (Look at an rc1 JAR
>>>> manifest for the hash? eww.) On the other hand, I can see a benefit in
>>>> removing inactive branches and tags to reduce clutter.
>>>>
>>>> 2. We could save a step, namely #7, by applying the increment to
>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT
>>>> instead of
>>>> on x.y.z. However, this would not leave a linear history, so I leave
>>>> it to
>>>> the more Git-savvy to decide if that is important in this case.
>>>>
>>>> Bill H
>>>>
>>>>
>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com>
>>>> wrote:
>>>>
>>>>   Looks good to me. I don't think it's too much work in the big
>>>> picture --
>>>>> it's what's necessary to get it done properly given the tool.
>>>>>
>>>>> The only ambiguity I see is in 3a), "make corrections _on
>>>>> x.y.z-SNAPSHOT_".
>>>>>
>>>>> Let's make sure this (assuming there aren't any objections) gets up on
>>>>> the
>>>>> site.
>>>>>
>>>>> - Josh
>>>>>
>>>>>
>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>>>
>>>>>   Taking this conversation from IRC because it probably needs to be
>>>>> on the
>>>>>> mailing list at some point. Also, we'll want to update the site
>>>>>> when we
>>>>>> have something we are happy with. Thanks to Christopher and Josh
>>>>>> for the
>>>>>> thoughts they've already contributed to the discussion.
>>>>>>
>>>>>> We need a standard procedure for generating RCs that is:
>>>>>> 1) Easily reproducible
>>>>>> 2) Compatible with ongoing development
>>>>>> 3) Compatible with our git branching model.
>>>>>>
>>>>>> The proposed process is:
>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of)
>>>>>> x.y.z-SNAPSHOT
>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>>>> 3) Perform testing and voting as necessary
>>>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>>>> 4) After a vote passes, tag the release on the same commit that
>>>>>> was the
>>>>>> rc
>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>>>> version)
>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the
>>>>>> current
>>>>>> tip
>>>>>> of x.y.z-SNAPSHOT
>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>>>
>>>>>> After having typed that all out it kind of seems like a lot of
>>>>>> steps to
>>>>>> go
>>>>>> through, but on the other hand, we're not going to be doing
>>>>>> everything
>>>>>> at
>>>>>> once anyway.
>>>>>>
>>>>>> Additional feedback would be awesome.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>

Re: [DISCUSS] How to generate RC's

[Josh Elser <jo...@gmail.com>]

On 1/13/14, 10:17 AM, Mike Drob wrote:
> #1 - No strong opinions.
> #2 - I want to make the transition for committers from one branch to the
> next as painless as possible. In particular, I'm worried that somebody will
> not realize they need to switch branched and accidentally push e.g.
> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
> want just a general 1.4 branch to deal with this case. (And similarly
> applied to the other lines.)
>
> What do you mean "put down the info... with the git-archive?" Listing the
> exact command?

Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate) 
shouldn't be harder than ensuring you have a GPG created.

> Another thought I had on this - what kind of tags are we using?
> Lightweight? Annotated? Signed?

I think Christopher had recommended a signed tag. ACCUMULO-1468 should 
have that definitively, but I'm not really up to date on what 
common/good practices are here.

> I think 1.4.4 has been the only git release, and I used a lightweight tag
> due to ignorance rather than choice.
>
> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com> wrote:
>
>> For #1, we typically haven't had a need/desire to keep around how we got
>> to a release (the RCs), but just the final release itself. If this is
>> something that has merit to it (besides trying to avoid the same mistakes
>> in future releases), I can't think of a good one. Maybe putting an RC-X
>> note in the commit message would be sufficient?
>>
>> #2, we could. I think the way Mike has this laid out is a little more
>> secure against people working already working on things for the next
>> release (or people who are still working on known bugs in a RC), but they
>> both do the same thing.
>>
>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document
>> this. Perhaps we can also put down the info you used for 1.4.4 with the
>> git-archive? We also should transcribe the mvn-deploy info from Christopher
>> that I have linked in the ticket.
>>
>>
>> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>>
>>> Overall, the process looks good, and I agree with Josh's clarification.
>>> Two
>>> pieces of feedback:
>>>
>>> 1. Step 8 removes a recording of the history leading to the release. For
>>> example, suppose rc1 is no good, and it takes three commits to get to rc2,
>>> which passes. When we remove the rc1 branch, how do we easily figure out
>>> months later which commit rc1 had been based on? (Look at an rc1 JAR
>>> manifest for the hash? eww.) On the other hand, I can see a benefit in
>>> removing inactive branches and tags to reduce clutter.
>>>
>>> 2. We could save a step, namely #7, by applying the increment to
>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT instead of
>>> on x.y.z. However, this would not leave a linear history, so I leave it to
>>> the more Git-savvy to decide if that is important in this case.
>>>
>>> Bill H
>>>
>>>
>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com> wrote:
>>>
>>>   Looks good to me. I don't think it's too much work in the big picture --
>>>> it's what's necessary to get it done properly given the tool.
>>>>
>>>> The only ambiguity I see is in 3a), "make corrections _on
>>>> x.y.z-SNAPSHOT_".
>>>>
>>>> Let's make sure this (assuming there aren't any objections) gets up on
>>>> the
>>>> site.
>>>>
>>>> - Josh
>>>>
>>>>
>>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>>
>>>>   Taking this conversation from IRC because it probably needs to be on the
>>>>> mailing list at some point. Also, we'll want to update the site when we
>>>>> have something we are happy with. Thanks to Christopher and Josh for the
>>>>> thoughts they've already contributed to the discussion.
>>>>>
>>>>> We need a standard procedure for generating RCs that is:
>>>>> 1) Easily reproducible
>>>>> 2) Compatible with ongoing development
>>>>> 3) Compatible with our git branching model.
>>>>>
>>>>> The proposed process is:
>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of) x.y.z-SNAPSHOT
>>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>>> 3) Perform testing and voting as necessary
>>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>>> 4) After a vote passes, tag the release on the same commit that was the
>>>>> rc
>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>>> version)
>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the current
>>>>> tip
>>>>> of x.y.z-SNAPSHOT
>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>>
>>>>> After having typed that all out it kind of seems like a lot of steps to
>>>>> go
>>>>> through, but on the other hand, we're not going to be doing everything
>>>>> at
>>>>> once anyway.
>>>>>
>>>>> Additional feedback would be awesome.
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>
>>>
>

Re: [DISCUSS] How to generate RC's

[Mike Drob <ma...@cloudera.com>]

#1 - No strong opinions.
#2 - I want to make the transition for committers from one branch to the
next as painless as possible. In particular, I'm worried that somebody will
not realize they need to switch branched and accidentally push e.g.
1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really
want just a general 1.4 branch to deal with this case. (And similarly
applied to the other lines.)

What do you mean "put down the info... with the git-archive?" Listing the
exact command?

Another thought I had on this - what kind of tags are we using?
Lightweight? Annotated? Signed?

I think 1.4.4 has been the only git release, and I used a lightweight tag
due to ignorance rather than choice.


On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <jo...@gmail.com> wrote:

> For #1, we typically haven't had a need/desire to keep around how we got
> to a release (the RCs), but just the final release itself. If this is
> something that has merit to it (besides trying to avoid the same mistakes
> in future releases), I can't think of a good one. Maybe putting an RC-X
> note in the commit message would be sufficient?
>
> #2, we could. I think the way Mike has this laid out is a little more
> secure against people working already working on things for the next
> release (or people who are still working on known bugs in a RC), but they
> both do the same thing.
>
> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document
> this. Perhaps we can also put down the info you used for 1.4.4 with the
> git-archive? We also should transcribe the mvn-deploy info from Christopher
> that I have linked in the ticket.
>
>
> On 1/9/14, 9:27 AM, Bill Havanki wrote:
>
>> Overall, the process looks good, and I agree with Josh's clarification.
>> Two
>> pieces of feedback:
>>
>> 1. Step 8 removes a recording of the history leading to the release. For
>> example, suppose rc1 is no good, and it takes three commits to get to rc2,
>> which passes. When we remove the rc1 branch, how do we easily figure out
>> months later which commit rc1 had been based on? (Look at an rc1 JAR
>> manifest for the hash? eww.) On the other hand, I can see a benefit in
>> removing inactive branches and tags to reduce clutter.
>>
>> 2. We could save a step, namely #7, by applying the increment to
>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT instead of
>> on x.y.z. However, this would not leave a linear history, so I leave it to
>> the more Git-savvy to decide if that is important in this case.
>>
>> Bill H
>>
>>
>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com> wrote:
>>
>>  Looks good to me. I don't think it's too much work in the big picture --
>>> it's what's necessary to get it done properly given the tool.
>>>
>>> The only ambiguity I see is in 3a), "make corrections _on
>>> x.y.z-SNAPSHOT_".
>>>
>>> Let's make sure this (assuming there aren't any objections) gets up on
>>> the
>>> site.
>>>
>>> - Josh
>>>
>>>
>>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>>
>>>  Taking this conversation from IRC because it probably needs to be on the
>>>> mailing list at some point. Also, we'll want to update the site when we
>>>> have something we are happy with. Thanks to Christopher and Josh for the
>>>> thoughts they've already contributed to the discussion.
>>>>
>>>> We need a standard procedure for generating RCs that is:
>>>> 1) Easily reproducible
>>>> 2) Compatible with ongoing development
>>>> 3) Compatible with our git branching model.
>>>>
>>>> The proposed process is:
>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of) x.y.z-SNAPSHOT
>>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>>> 3) Perform testing and voting as necessary
>>>> 3a) If the vote fails, make corrections and start over at 1)
>>>> 4) After a vote passes, tag the release on the same commit that was the
>>>> rc
>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT
>>>> version)
>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the current
>>>> tip
>>>> of x.y.z-SNAPSHOT
>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>>
>>>> After having typed that all out it kind of seems like a lot of steps to
>>>> go
>>>> through, but on the other hand, we're not going to be doing everything
>>>> at
>>>> once anyway.
>>>>
>>>> Additional feedback would be awesome.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>
>>

Re: [DISCUSS] How to generate RC's

[Josh Elser <jo...@gmail.com>]

For #1, we typically haven't had a need/desire to keep around how we got 
to a release (the RCs), but just the final release itself. If this is 
something that has merit to it (besides trying to avoid the same 
mistakes in future releases), I can't think of a good one. Maybe putting 
an RC-X note in the commit message would be sufficient?

#2, we could. I think the way Mike has this laid out is a little more 
secure against people working already working on things for the next 
release (or people who are still working on known bugs in a RC), but 
they both do the same thing.

Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document 
this. Perhaps we can also put down the info you used for 1.4.4 with the 
git-archive? We also should transcribe the mvn-deploy info from 
Christopher that I have linked in the ticket.

On 1/9/14, 9:27 AM, Bill Havanki wrote:
> Overall, the process looks good, and I agree with Josh's clarification. Two
> pieces of feedback:
>
> 1. Step 8 removes a recording of the history leading to the release. For
> example, suppose rc1 is no good, and it takes three commits to get to rc2,
> which passes. When we remove the rc1 branch, how do we easily figure out
> months later which commit rc1 had been based on? (Look at an rc1 JAR
> manifest for the hash? eww.) On the other hand, I can see a benefit in
> removing inactive branches and tags to reduce clutter.
>
> 2. We could save a step, namely #7, by applying the increment to
> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT instead of
> on x.y.z. However, this would not leave a linear history, so I leave it to
> the more Git-savvy to decide if that is important in this case.
>
> Bill H
>
>
> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com> wrote:
>
>> Looks good to me. I don't think it's too much work in the big picture --
>> it's what's necessary to get it done properly given the tool.
>>
>> The only ambiguity I see is in 3a), "make corrections _on x.y.z-SNAPSHOT_".
>>
>> Let's make sure this (assuming there aren't any objections) gets up on the
>> site.
>>
>> - Josh
>>
>>
>> On 1/8/14, 7:58 PM, Mike Drob wrote:
>>
>>> Taking this conversation from IRC because it probably needs to be on the
>>> mailing list at some point. Also, we'll want to update the site when we
>>> have something we are happy with. Thanks to Christopher and Josh for the
>>> thoughts they've already contributed to the discussion.
>>>
>>> We need a standard procedure for generating RCs that is:
>>> 1) Easily reproducible
>>> 2) Compatible with ongoing development
>>> 3) Compatible with our git branching model.
>>>
>>> The proposed process is:
>>> 1) Create an RC branch named x.y.z-rcN from (the tip of) x.y.z-SNAPSHOT
>>> 2) Commit pom version changes to the branch, tag as rc, and push
>>> 3) Perform testing and voting as necessary
>>> 3a) If the vote fails, make corrections and start over at 1)
>>> 4) After a vote passes, tag the release on the same commit that was the rc
>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT version)
>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the current tip
>>> of x.y.z-SNAPSHOT
>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>>
>>> After having typed that all out it kind of seems like a lot of steps to go
>>> through, but on the other hand, we're not going to be doing everything at
>>> once anyway.
>>>
>>> Additional feedback would be awesome.
>>>
>>> Mike
>>>
>>>
>
>

Re: [DISCUSS] How to generate RC's

[Bill Havanki <bh...@clouderagovt.com>]

Overall, the process looks good, and I agree with Josh's clarification. Two
pieces of feedback:

1. Step 8 removes a recording of the history leading to the release. For
example, suppose rc1 is no good, and it takes three commits to get to rc2,
which passes. When we remove the rc1 branch, how do we easily figure out
months later which commit rc1 had been based on? (Look at an rc1 JAR
manifest for the hash? eww.) On the other hand, I can see a benefit in
removing inactive branches and tags to reduce clutter.

2. We could save a step, namely #7, by applying the increment to
x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT instead of
on x.y.z. However, this would not leave a linear history, so I leave it to
the more Git-savvy to decide if that is important in this case.

Bill H


On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <jo...@gmail.com> wrote:

> Looks good to me. I don't think it's too much work in the big picture --
> it's what's necessary to get it done properly given the tool.
>
> The only ambiguity I see is in 3a), "make corrections _on x.y.z-SNAPSHOT_".
>
> Let's make sure this (assuming there aren't any objections) gets up on the
> site.
>
> - Josh
>
>
> On 1/8/14, 7:58 PM, Mike Drob wrote:
>
>> Taking this conversation from IRC because it probably needs to be on the
>> mailing list at some point. Also, we'll want to update the site when we
>> have something we are happy with. Thanks to Christopher and Josh for the
>> thoughts they've already contributed to the discussion.
>>
>> We need a standard procedure for generating RCs that is:
>> 1) Easily reproducible
>> 2) Compatible with ongoing development
>> 3) Compatible with our git branching model.
>>
>> The proposed process is:
>> 1) Create an RC branch named x.y.z-rcN from (the tip of) x.y.z-SNAPSHOT
>> 2) Commit pom version changes to the branch, tag as rc, and push
>> 3) Perform testing and voting as necessary
>> 3a) If the vote fails, make corrections and start over at 1)
>> 4) After a vote passes, tag the release on the same commit that was the rc
>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT version)
>> 6) Create a new development branch x.y.a-SNAPSHOT based on the current tip
>> of x.y.z-SNAPSHOT
>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>>
>> After having typed that all out it kind of seems like a lot of steps to go
>> through, but on the other hand, we're not going to be doing everything at
>> once anyway.
>>
>> Additional feedback would be awesome.
>>
>> Mike
>>
>>


-- 
| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -

Re: [DISCUSS] How to generate RC's

[Josh Elser <jo...@gmail.com>]

Looks good to me. I don't think it's too much work in the big picture -- 
it's what's necessary to get it done properly given the tool.

The only ambiguity I see is in 3a), "make corrections _on x.y.z-SNAPSHOT_".

Let's make sure this (assuming there aren't any objections) gets up on 
the site.

- Josh

On 1/8/14, 7:58 PM, Mike Drob wrote:
> Taking this conversation from IRC because it probably needs to be on the
> mailing list at some point. Also, we'll want to update the site when we
> have something we are happy with. Thanks to Christopher and Josh for the
> thoughts they've already contributed to the discussion.
>
> We need a standard procedure for generating RCs that is:
> 1) Easily reproducible
> 2) Compatible with ongoing development
> 3) Compatible with our git branching model.
>
> The proposed process is:
> 1) Create an RC branch named x.y.z-rcN from (the tip of) x.y.z-SNAPSHOT
> 2) Commit pom version changes to the branch, tag as rc, and push
> 3) Perform testing and voting as necessary
> 3a) If the vote fails, make corrections and start over at 1)
> 4) After a vote passes, tag the release on the same commit that was the rc
> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT version)
> 6) Create a new development branch x.y.a-SNAPSHOT based on the current tip
> of x.y.z-SNAPSHOT
> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch
> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT
>
> After having typed that all out it kind of seems like a lot of steps to go
> through, but on the other hand, we're not going to be doing everything at
> once anyway.
>
> Additional feedback would be awesome.
>
> Mike
>