Am Wed, 31 Dec 2014 09:29:16 -0500 schrieb Gary Gregory <garydgreg...@gmail.com>:
> On Wed, Dec 31, 2014 at 12:16 AM, 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 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 <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.) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
