Hello sebb, Am Wed, 31 Dec 2014 12:49:17 +0000 schrieb sebb <seb...@gmail.com>:
> 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? > > > > 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
