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 <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
