Hello Christopher,
Am Wed, 31 Dec 2014 10:26:31 -0500
schrieb Christopher <ctubb...@apache.org>:
> On Wed, Dec 31, 2014 at 7:49 AM, sebb <seb...@gmail.com> wrote:
>
> > On 31 December 2014 at 05:16, Bernd Eckenfels
> > <e...@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?
> 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.wiedm...@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-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
