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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>> >
