You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Bernd Eckenfels <ec...@zusammenkunft.net> on 2014/12/31 06:16:11 UTC
[All] Release Plugin (was: [All] Moving to git)
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?
Gruss
Bernd
At work I use the release plugin quite heavily Am Wed, 31 Dec 2014
01:38:14 +0100 schrieb Jochen Wiedmann <jo...@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
Re: [All] Release Plugin (was: [All] Moving to git)
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am Wed, 31 Dec 2014 09:29:16 -0500
schrieb Gary Gregory <ga...@gmail.com>:
> On Wed, Dec 31, 2014 at 12:16 AM, Bernd Eckenfels
> <ec...@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 sure seems messy to me. The process of _adding_ release tag
> which is the same as the successful RC tag seems clear and simple (to
> me). This is what I've been doing since day 1.
I agree, however I dont see a better solution when the release-plugin
is used. Usage of the release-plugin is described in the Commons
Release Guide, so I asume this "messy" procedure is accepted. So unless
somebody vetos it or suggest a better method, I would like to use it.
Gruss
Bernd
>
> Gary
>
> >
> > 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?
> >
> > At work I use the release plugin quite heavily Am Wed, 31 Dec 2014
> > 01:38:14 +0100 schrieb Jochen Wiedmann <jo...@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.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Release Plugin (was: [All] Moving to git)
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Dec 31, 2014 at 12:16 AM, Bernd Eckenfels <ec...@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 sure seems messy to me. The process of _adding_ release tag which is
the same as the successful RC tag seems clear and simple (to me). This is
what I've been doing since day 1.
Gary
>
> 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?
>
> Gruss
> Bernd
>
>
>
>
>
>
>
> At work I use the release plugin quite heavily Am Wed, 31 Dec 2014
> 01:38:14 +0100 schrieb Jochen Wiedmann <jo...@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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [All] Release Plugin (was: [All] Moving to git)
Posted by Christopher <ct...@apache.org>.
On Wed, Dec 31, 2014 at 11:24 AM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:
> Hello Christopher,
>
> Am Wed, 31 Dec 2014 10:26:31 -0500
> schrieb Christopher <ct...@apache.org>:
>
> > On Wed, Dec 31, 2014 at 7:49 AM, sebb <se...@gmail.com> wrote:
> >
> > > On 31 December 2014 at 05:16, Bernd Eckenfels
> > > <ec...@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
> > > > <jo...@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
>
>
Re: [All] Release Plugin (was: [All] Moving to git)
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello Christopher,
Am Wed, 31 Dec 2014 10:26:31 -0500
schrieb Christopher <ct...@apache.org>:
> On Wed, Dec 31, 2014 at 7:49 AM, sebb <se...@gmail.com> wrote:
>
> > On 31 December 2014 at 05:16, Bernd Eckenfels
> > <ec...@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
> > > <jo...@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
Re: [All] Release Plugin (was: [All] Moving to git)
Posted by Christopher <ct...@apache.org>.
On Wed, Dec 31, 2014 at 7:49 AM, sebb <se...@gmail.com> wrote:
> On 31 December 2014 at 05:16, Bernd Eckenfels <ec...@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?
> >
> > Gruss
> > Bernd
> >
> >
>
> 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 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
> >
> >
> >
> >
> > At work I use the release plugin quite heavily Am Wed, 31 Dec 2014
> > 01:38:14 +0100 schrieb Jochen Wiedmann <jo...@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
>
>
Re: [All] Release Plugin
Posted by sebb <se...@gmail.com>.
On 31 December 2014 at 14:45, Bernd Eckenfels <ec...@zusammenkunft.net> wrote:
> Hello sebb,
>
> Am Wed, 31 Dec 2014 12:49:17 +0000
> schrieb sebb <se...@gmail.com>:
>
>> On 31 December 2014 at 05:16, Bernd Eckenfels
>> <ec...@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?
>> >
>> > Gruss
>> > Bernd
>> >
>> >
>>
>> The reasons I don't use the Release Plugin are:
>> - the actions it takes are poorly documented
>
> Not sure about that, however it is a complicated thing so you typically
> dont remeber all the steps without looking it up.
> http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
> http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
>
>> - it does not use a clean workspace checkout of the tag
>
> Hm, at prepare it does check the workspace for unclean files. The
> actual release build (with release:perform) does check out a fresh
> workspace from tag.
Are you sure about that?
>> - trunk is automatically updated to the next SNAPSHOT version. This is
>> unnecessary.
>
> I think you can skip this with updateWorkingCopyVersions=false. I dont
> think it is "unecessary", it is just "too early" done at release time.
> The prepare commit for next version should be done after the vote (for
> the reasons you mentioned). So it is better done manually.
Indeed
>> - if a release vote fails (or the RM realises they have forgotten
>> something) trunk has to be reverted.
>
> I think with updateWorkingCopyVersions=false and
> suppressCommitBeforeTag=true this is not the case, but I will have to
> check.
It's definitely possible to create a tag from trunk plus uncommitted changes;
that's what the manual process does.
Whether RP has the code to do this I don't know.
> Still the failed tag has to be renamed.
Not sure what you mean by that.
>> 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.
>
> Hopefully this can be avoided (see above)
>
>> 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.
>
> I agree (on the other hand it makes releaes more predictable, it
Not unless a clean workspace is used; it's all too easy to
accidentally bundle test and temporary files.
> ensures the right command line and environment, it does some tests and
> it adds scm/tag information - which is seldomly done correctly in all
> the latest commons releases.
If you look through the mail archives you will see lots ot cases where
it takes the RM several tries before producing an RC that is OK.
This does not happen so much with the manual process.
That may be because of the relative experience of the different RMs,
but I think it's clear that the RP is not as easy to use as some
people say, nor is it reliable under adverse network conditions.
> Gruss
> Bernd
>
> ---------------------------------------------------------------------
> 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
Re: [All] Release Plugin
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello sebb,
Am Wed, 31 Dec 2014 12:49:17 +0000
schrieb sebb <se...@gmail.com>:
> On 31 December 2014 at 05:16, Bernd Eckenfels
> <ec...@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?
> >
> > Gruss
> > Bernd
> >
> >
>
> The reasons I don't use the Release Plugin are:
> - the actions it takes are poorly documented
Not sure about that, however it is a complicated thing so you typically
dont remeber all the steps without looking it up.
http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
> - it does not use a clean workspace checkout of the tag
Hm, at prepare it does check the workspace for unclean files. The
actual release build (with release:perform) does check out a fresh
workspace from tag.
> - trunk is automatically updated to the next SNAPSHOT version. This is
> unnecessary.
I think you can skip this with updateWorkingCopyVersions=false. I dont
think it is "unecessary", it is just "too early" done at release time.
The prepare commit for next version should be done after the vote (for
the reasons you mentioned). So it is better done manually.
> - if a release vote fails (or the RM realises they have forgotten
> something) trunk has to be reverted.
I think with updateWorkingCopyVersions=false and
suppressCommitBeforeTag=true this is not the case, but I will have to
check. Still the failed tag has to be renamed.
> 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.
Hopefully this can be avoided (see above)
> 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.
I agree (on the other hand it makes releaes more predictable, it
ensures the right command line and environment, it does some tests and
it adds scm/tag information - which is seldomly done correctly in all
the latest commons releases.
Gruss
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Release Plugin (was: [All] Moving to git)
Posted by sebb <se...@gmail.com>.
On 31 December 2014 at 05:16, Bernd Eckenfels <ec...@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?
>
> Gruss
> Bernd
>
>
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.
>
>
>
>
> At work I use the release plugin quite heavily Am Wed, 31 Dec 2014
> 01:38:14 +0100 schrieb Jochen Wiedmann <jo...@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
Re: [All] Release Plugin
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello Luc,
Am Wed, 31 Dec 2014 13:57:47 +0100
schrieb Luc Maisonobe <lu...@spaceroots.org>:
> Le 31/12/2014 06:16, Bernd Eckenfels a écrit :
> > 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.
>
> You can look at the release howto we have at [math] here:
> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=blob_plain;f=doc/release/release.howto.txt;hb=HEAD>.
> This howto was written by Gilles and I updated it for git usage. The
> 3.4 release from last week
> was done using this process.
Thanks, I have seen that. The problem is it wont apply to
release-plugin releases, but it is helpful for all the steps around the
release.
> The idea was to have a branch for the release candidates, and to set
> up tags (which can be cryptographically sign in Git) with RC numbers
> as successive candidates were drawn.
I understand the process, the problem is you cannot do it with the
release-plugin this way. Because if you tell it to create a
"commons-vfs2-2.1-RC1" tag, then it will also put this tag inside the
POM, which is not what you want to have when it is later the final
candidate.
> None of the tags are ever
> removed. When the final RC vote succeeds, an additional tag was put
> on the same commit to remember this was the selected one.
I am not talking about removing RC tags which are actual candidates, I
was talking about rolling back which is needed for the release plugin
as it wants to do all steps in a single action (and as those are
sometimes network related they can fail).
> In git
> world, tags are put "on" a commit, they do not modify the commit,
> they just correspond to something you stick on it to give it a name
> easier to remember than a SHA1 checksum. They can be put long after
> the commit was done. So the final MATH_3_4 tag in our case was
> applied after the vote, on the same commit tag MATH_3_4_RC3 was
> applied to (but obviously MATH_3_4_RC3 was created before the vote).
Yes, but when you do it manual, you can put the right tag into the POM
(MATH_3_4), for the release-plugin it would be MATH_3_4_RC3.
BTW: you relesed POM does not contain the tag, it points to the master
branch. You should add that to your build process. For SVN you put the
tag in the url for git you add <scn>...<tag>MATH_3_4</tag></scm>.
> We didn't use the release plugin.
>
>
> >
> > 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).
>
> If release plugin relies on buildnumber-maven-plugin, you should check
> if it works. It is expected to work, but I was not able to have it
> extract correctly the version.
I dont think it does rely, but of course the build does. (and it works
I think, however its not an issue for this release, I want to cut it
from SVN).
> See my previous message here:
> <http://markmail.org/message/zg2udhrwrlsjxahx>. I had to switch to
> maven-jgit-buildnumber-plugin. I did not had time to investigate this
> further, but I would clearly prefer to come back to
> buildnumber-maven-plugin and have some configuration set up in parent
> pom to switch automatically.
I think the only problem is scmBranch which is not set, but we also not
use it.
> > - vote on it
> > - if the vote passes, promote the realse
> > - if the vote fails rename the scm tags to the -RCy
>
> This sound overly complicated. Adding tags is possible, so it should
> probably be prefered to removing tags. Basically, the final commit
> is both RCy and final, so it deserves having two tags.
The reason for the complicated process is, because I want to have the
correct tag in the released POM.
>
> >
> > 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.
>
> Why not? What we did for [math] was creating a release-candidates
> branch, cutting all RC from there (and merging master back into this
> branch as fixes were introduced in master after failed votes), and at
> the end the release-candidates branch was merged back to master and
> deleted.
I think the release-plugin can work on a rc branch, but it cannot make
the release commit (the one with the non-snapshot pom) independend of
this branch. (the question is if the RCtags and the release tag point
to a commit on the master branch or not. From reading the list, it is
prefered to not be on master/trunk).
> In git, a branch is simply a name pointing to a place in the
> history and moving along as new commits are added on it. Deleting the
> branch after it has been merged is not deleting the underlying
> commits, it is just deleting the name "release-candidates" as it is
> not useful anymore. The commits are safe, and the changes have been
> merged back into master so they will stay there for posterity. The
> name release-candidates can be reused when the next release will be
> worked on.
Yes sure, its most likely a good method - at least for Git.
> So I do not understand what you are saying about immutable objects.
> Branches are not immutable. Commits are immutable, but they can be
> created on a temporary branch. When the branch will be merged back,
> those commits will be part of the shared history of several other
> branches, regardless of the original branch being deleted or not.
I was talking about deleting failed tags - in the context of the
release-plugin (as it tends to fail often).
Gruss
Bernd
> best regards,
> Luc
>
> >
> > Or maybe lets shortcut this mail: is there a release-plugin using
> > commons subproject with a documentation on the whole process?
> >
> > Gruss
> > Bernd
> >
> >
> >
> >
> >
> >
> >
> > At work I use the release plugin quite heavily Am Wed, 31 Dec 2014
> > 01:38:14 +0100 schrieb Jochen Wiedmann <jo...@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
Re: [All] Release Plugin
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 31/12/2014 06:16, Bernd Eckenfels a écrit :
> Hello,
Hi Bernd,
>
> 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.
You can look at the release howto we have at [math] here:
<https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=blob_plain;f=doc/release/release.howto.txt;hb=HEAD>.
This howto was written by Gilles and I updated it for git usage. The 3.4
release from last week
was done using this process.
The idea was to have a branch for the release candidates, and to set
up tags (which can be cryptographically sign in Git) with RC numbers as
successive candidates were drawn. None of the tags are ever removed.
When the final RC vote succeeds, an additional tag was put on the same
commit to remember this was the selected one. In git world, tags are
put "on" a commit, they do not modify the commit, they just correspond
to something you stick on it to give it a name easier to remember than
a SHA1 checksum. They can be put long after the commit was done. So the
final MATH_3_4 tag in our case was applied after the vote, on the same
commit tag MATH_3_4_RC3 was applied to (but obviously MATH_3_4_RC3 was
created before the vote).
We didn't use the release plugin.
>
> 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).
If release plugin relies on buildnumber-maven-plugin, you should check
if it works. It is expected to work, but I was not able to have it
extract correctly the version. See my previous message here:
<http://markmail.org/message/zg2udhrwrlsjxahx>. I had to switch to
maven-jgit-buildnumber-plugin. I did not had time to investigate this
further, but I would clearly prefer to come back to
buildnumber-maven-plugin and have some configuration set up in parent
pom to switch automatically.
> - vote on it
> - if the vote passes, promote the realse
> - if the vote fails rename the scm tags to the -RCy
This sound overly complicated. Adding tags is possible, so it should
probably be prefered to removing tags. Basically, the final commit
is both RCy and final, so it deserves having two tags.
>
> 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.
Why not? What we did for [math] was creating a release-candidates
branch, cutting all RC from there (and merging master back into this
branch as fixes were introduced in master after failed votes), and at
the end the release-candidates branch was merged back to master and
deleted. In git, a branch is simply a name pointing to a place in the
history and moving along as new commits are added on it. Deleting the
branch after it has been merged is not deleting the underlying commits,
it is just deleting the name "release-candidates" as it is not useful
anymore. The commits are safe, and the changes have been merged back
into master so they will stay there for posterity. The name
release-candidates can be reused when the next release will be worked on.
So I do not understand what you are saying about immutable objects.
Branches are not immutable. Commits are immutable, but they can be
created on a temporary branch. When the branch will be merged back,
those commits will be part of the shared history of several other
branches, regardless of the original branch being deleted or not.
best regards,
Luc
>
> Or maybe lets shortcut this mail: is there a release-plugin using
> commons subproject with a documentation on the whole process?
>
> Gruss
> Bernd
>
>
>
>
>
>
>
> At work I use the release plugin quite heavily Am Wed, 31 Dec 2014
> 01:38:14 +0100 schrieb Jochen Wiedmann <jo...@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