accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [DISCUSS] How to generate RC's
Date Tue, 11 Feb 2014 21:17:17 GMT
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 <ctubbsii@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 <josh.elser@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 <josh.elser@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 <josh.elser@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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message