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. 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 <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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@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
