commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [All] Release Plugin (was: [All] Moving to git)
Date Wed, 31 Dec 2014 20:34:43 GMT
On Wed, Dec 31, 2014 at 11:24 AM, Bernd Eckenfels <ecki@zusammenkunft.net>
wrote:

> Hello Christopher,
>
> Am Wed, 31 Dec 2014 10:26:31 -0500
> schrieb Christopher <ctubbsii@apache.org>:
>
> > On Wed, Dec 31, 2014 at 7:49 AM, sebb <sebbaz@gmail.com> wrote:
> >
> > > On 31 December 2014 at 05:16, Bernd Eckenfels
> > > <ecki@zusammenkunft.net> wrote:
> > > > Hello,
> > > >
> > > > Jochen asked about the release plugin in the context of Git
> > > > migration. It might safe routine work for releases, but it seems
> > > > to me also underspecified in the context of Apache Commons (with
> > > > SVN and Git)
> > > >
> > > > [VFS] uses the release plugin (at least the last release did). I
> > > > intent to do the next release with it (I have some experience at
> > > > work with the release plugin (and Git)).
> > > >
> > > > However there are still a few open points I had raised in one of
> > > > my last mails (and they are not Git specific):
> > > >
> > > > - I dont know of a way to cut a RC which later on gets turned
> > > > into a release (like most Commons projects which are manually
> > > > released do). The reason for this is: it will put the scm tag it
> > > > uses (which would be a commons-vfs-2.1-RC1) into the SCM URL. (so
> > > > if you want to create a RC with the final scm url but without
> > > > applying the final tag to svn/git for later creation, this wont
> > > > work).
> > > >
> > > > At least I dont know how. So there would be two possible
> > > > alternatives: you either have to cut a RC with a RC-tag first and
> > > > then re-run the process with the release. (it is unclear how much
> > > > we need to vote then).
> > > >
> > > > Or it could mean, that a final version tag could be created before
> > > > vote, and needs to be rolled back if the vote fails. It seems to
> > > > be frowned upon touching such tags, but I havent received an
> > > > alternative suggestion which would work.
> > > >
> > > > Ralph documented a release process for log4j2 with the release
> > > > plugin where he would use the final product version to stage a
> > > > candidate. If the vote fails he would rename the released that to
> > > > a RC, but he runs all release-plugin invocations with the final
> > > > version. This would be my prefered way as well.
> > > >
> > > > I also expect (especially with SVN where the push cannot be
> > > > delayed like in Git) that some tries with the release-plugin
> > > > fail. I know this from experience and I would feel very uneasy if
> > > > it is not allowd to remove/rename those failed tags.
> > > >
> > > > My current preferd method would look like:
> > > >
> > > > - cut a release candidate with a -RC1 scm tag with the release
> > > > plugin. Publish the result for review. (when something fails
> > > > abandon the RC tag and use the next one).
> > > > - iterate as long as there a major concerns (this actually
> > > > requires some reviewers before the vote please!)
> > > > - once I feel confident that a RC might pass the review/vote I
> > > > will actually cut the next RC specifying the final (non -RC) tag.
> > > > This will produce archives with the proper version-number in the
> > > > scmtag, it also will generate a scm tag with the final version
> > > > number (and staged artifacts).
> > > > - vote on it
> > > >   - if the vote passes, promote the realse
> > > >   - if the vote fails rename the scm tags to the -RCy
> > > >
> > > > This (with the additional RC step) is basically like Ralph
> > > > documented it for log4j2. How can I get a decision on this
> > > > process? Can I call for a vote if this is acceptable? (it will
> > > > work for SVN and GIT).
> > > >
> > > >
> > > > BTW: I think normally the release plugin will not make the release
> > > > version in its own branch, it will show up in trunk/master. I
> > > > think it might be configured differently with using a branch. But
> > > > given the fact that those scn objects are rather immutable, I do
> > > > not even try to use that.
> > > >
> > > > Or maybe lets shortcut this mail: is there a release-plugin using
> > > > commons subproject with a documentation on the whole process?
>
> > > The reasons I don't use the Release Plugin are:
> > > - the actions it takes are poorly documented
> > > - it does not use a clean workspace checkout of the tag
> > > - trunk is automatically updated to the next SNAPSHOT version. This
> > > is unnecessary.
> > > - if a release vote fails (or the RM realises they have forgotten
> > > something) trunk has to be reverted.
> > >
> > > The changes to trunk do not play well with CI systems which upload
> > > snapshots.
> > > If the RC fails for any reason, trunk will revert to the previous
> > > snapshot, and any further snapshots will be regarded as older unless
> > > any newer snapshots are deleted.
> > >
> > > I think these are design failures which could/should be fixed.
> > > Meanwhile I prefer to use manual methods, as recovery is so much
> > > easier, and the build process is more secure when using a fresh
> > > checkout of the actual tag.
>
> > These are fair. However, I will say that using the release plugin
> > with git, is *much* nicer. The Accumulo team switched to git, and had
> > used the release plugin both before and after that switch. I think
> > it's much easier after the switch, because one can do everything
> > locally, without pushing any of the modifications until needed. It's
> > very easy to abandon a branch if a vote fails, and simply choose not
> > to merge it in or release/push a tag. You can push the RC to a
> > separate branch or tag, for considerations, so it doesn't interfere
> > with CI snapshots, and you can merge the commits which bump to the
> > next snapshot version (if you choose to), only after the vote passes.
> >
> > We also override set the <tag> element in the <scm> section of the
> > pom to be ${project.version} so it matches what the final tag name
>
> I see you use
>
> <tagNameFormat>@{project.version}</tagNameFormat>
>
> Does this only influence the tag in the pom? I would expect this to
> also remove the RCx from the tag used for push?
>
>
It affects both. However, it is just a hint and used only if the user does
not enter their own when prompted. To address the pom correctness issue, we
override this by explicitly setting the tag to
<tag>${project.version}</tag>, so the pom is correct regardless of
tagNameFormat. That was needed when we were using Subversion. We used to
actually have the tagNameFormat set to @{project.version}-RC to give a
better hint at what it should look like. A user would still have to
manually enter the full version with the correct RC number (1.5.1-RC1,
1.5.1-RC2, etc.)

With Git, we have greater control and it's a bit easier. We use
<pushChanges>false</pushChanges> and <localCheckout>true</localCheckout>,
so the release plugin creates the proper commits in the branch and creates
the tag. But, we rename them before pushing for vote, so they are only
pushed with acceptable RCn names.

For example, to release 1.5.1 from the 1.5 branch:

git checkout -b 1.5.1-releasing origin/1.5 # create a local branch to
prepare a release
mvn release:prepare && mvn release:perform # build the release
git checkout -b 1.5.1-RC1 1.5.1  # or git checkout -b 1.5.1-RC1 HEAD~1
git tag -d 1.5.1 # remove the unneeded tag
git push origin 1.5.1-RC1 # upload RC1 for voting

If vote fails:

git branch -D 1.5.1-RC1 1.5.1-releasing # abandon local branches w/o merging
git push --delete origin 1.5.1-RC1 # delete the remote RC branch; optional

If the vote passes:

git tag -s 1.5.1 1.5.1-RC1 # gpg sign the tag
git push --tags # push the tag
git checkout -t origin/1.5 # check out the 1.5 dev branch
git merge 1.5.1-releasing # merge in the commits which bump the version
git push # push the merged commits
git branch -d 1.5.1-releasing # no longer needed
git push --delete origin 1.5.1-RC1 # delete the remote RC branch; optional

This seems like a lot of steps... but actually, it's quite intuitive once
you understand what you are trying to accomplish, and are familiar with how
that maps to what's going on in git.



> > will be if the vote passes, and not the temporary RC's tag name from
> > the interactive prompt. You might be able to do something similar
> > with SVN as the SCM (in conjunction with <tagBase>)... I'm not sure.
> >
> >
> https://repo1.maven.org/maven2/org/apache/accumulo/accumulo/1.6.1/accumulo-1.6.1.pom
>
> Greetings
> Bernd
>
> > > > At work I use the release plugin quite heavily Am Wed, 31 Dec 2014
> > > > 01:38:14 +0100 schrieb Jochen Wiedmann
> > > > <jochen.wiedmann@gmail.com>:
> > > >
> > > >> 1.) And why don't you intend to use this plugin? I know, it is a
> > > >> non-trivial task to use it, but
> > > >>      my impression is that it's worth to struggle yourself
> > > >> through. 2.) Has anyone already attempted to use the release
> > > >> plugin with git? Is that possible in our
> > > >>      scenario? (Have to admit, I still don't really understand
> > > >> the relationship between the old
> > > >>      svn repo and a new git repo.)
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Jochen
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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