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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > >>>>> 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 <[email protected]> > >>>>>>> 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>> > > >
