We have never deleted a tag once a vote passed. Now that tags are immutable we are using rcn tags and then creating a release tag when the vote passes. But we are still just using the release plugin.
Ralph > On May 5, 2016, at 9:49 AM, sebb <seb...@gmail.com> wrote: > > On 5 May 2016 at 17:08, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: >> I really don’t know why you are making such a big deal about this. > > Because it's important that tags are immutable, and to to a lesser > degree to avoid creating spurious snapshot builds. > >> I’ve been using the maven release plugin to release Log4j 2 for several >> years. That build was created based on the VFS 2.0 release process that also >> used the maven release plugin. As I have said several times, releasing VFS >> is a lot harder than the rest of Commons because almost all are single >> module projects. Log4j 2 has a ton of modules and doesn’t have any >> significant problems that can’t easily be dealt with. > > However the Log4j tags have not been immutable. > > Both 2.0.1 and 2.0.2 were updated after initial creation. > > And the 2.0-beta8 tag was created and deleted several times. > There are other instances of mutable tags. > > This means it may be tricky to demonstrate that the final tag > corresponds with what was actually voted on. > > It also looks like 2.0 was created from trunk rather than either of the RCs. > As it happens, that vote passed first time so there was no need to recreate > 2.0. > What would you have done if that vote had failed? > > >> The process Josh documented for the 2.release seems a bit more complicated >> than what I did for 2.0, but if it works for him, great. >> >> Ralph >> >> >>> On May 5, 2016, at 6:41 AM, sebb <seb...@gmail.com >>> <mailto:seb...@gmail.com>> wrote: >>> >>> On 5 May 2016 at 13:29, Benedikt Ritter <brit...@apache.org >>> <mailto:brit...@apache.org> <mailto:brit...@apache.org >>> <mailto:brit...@apache.org>>> wrote: >>>> sebb <seb...@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr: >>>> >>>>> On 5 May 2016 at 12:22, <e...@zusammenkunft.net> wrote: >>>>>> Hello, >>>>>> >>>>>> BTW: I would use "mvn verify" instead of "mvn package" (I am not sure >>>>> what has changed for CP40) >>>>> >>>>> CP40 changed the assembly plugin to run in the verify phase so it can >>>>> pick up any additional jars added to the package phase by component >>>>> poms. >>>>> [It's not possible to ensure the assembly plugin runs at the very end >>>>> of the assembly phase - see COMMONSSITE-87] >>>>> >>>>> Releases should be generated using >>>>> >>>>> mvn deploy -Prelease >>>>> >>>>> 'mvn package' should still work for generating jars. >>>>> >>>>>> (And yes the release plugin and the commons procedure for releases is a >>>>> match in hell ,) >>>>> >>>>> Not just Commons. >>>>> Any project which allows multiple RCs for the same release is affected. >>>>> The plugin works best where failed releases are abandoned and the >>>>> version bumped for the next RC. >>>>> It does not play well with retries. >>>>> >>>> >>>> I wonder how the maven-release-plugin team does this. Don't they run into >>>> the same problems? >>>> >>> >>> The problems I can remember are: >>> - trunk is unconditionally updated to the next SNAPSHOT version. >>> This causes problems for components using CI builds (which may not be >>> the case for them). >>> >>> - if an RC fails, trunk has to be reverted. >>> Since RC failures are quite common, the process should be designed >>> accordingly. >>> Subsequent CI builds will use an earlier SNAPSHOT version, which is >>> confusing. >>> >>> - does it create an immutable tag? I cannot work out from the docs >>> whether it appends RCn to the tag or not. >>> If not, then redoing a failed release as the next RC will require >>> deleting and recreating the tag, or abandoning that release version >>> and starting again with the next version number. >>> If it does create an RC tag, what name does it use for the SCM URLs? >>> >>> - the local trunk workspace contains status files which need to be >>> preseved until the process is complete. >>> >>> >>>>> >>>>> [1] https://issues.apache.org/jira/browse/COMMONSSITE-87 >>>>> >>>>>> Gruss >>>>>> Bernd >>>>>> -- >>>>>> http://bernd.eckenfels.net >>>>>> >>>>>> -----Original Message----- >>>>>> From: Josh Elser <els...@apache.org> >>>>>> To: Commons Developers List <dev@commons.apache.org> >>>>>> Sent: Do., 05 Mai 2016 6:49 >>>>>> Subject: Re: [VFS] WIP specific release instructions >>>>>> >>>>>> >>>>>> >>>>>> sebb wrote: >>>>>>> Have a look at the scripts in >>>>>>> >>>>>>> http://svn.apache.org/viewvc/commons/scripts/ >>>>>>> >>>>>>> I used those for VALIDATOR and NET. >>>>>> >>>>>> Cool. Thanks for sharing. It would be good if the generic commons >>>>>> release documents referenced these if they are expected to be re-used by >>>>>> other commons projects' RMs. >>>>>> >>>>>>> On 4 May 2016 at 04:43, Josh Elser<els...@apache.org> wrote: >>>>>>>> Here's what I've been doing. The generic instructions are woefully >>>>>>>> incomplete (before someone chimes in again - no, not just because "VFS >>>>> is a >>>>>>>> multi-module project"). I think I have this on point for rc1, so I'm >>>>> writing >>>>>>>> it down here before I forget (we can figure out where it *should* go >>>>> later). >>>>>>>> >>>>>>>> rc0 only: >>>>>>>> # Make the branch >>>>>>>> $ svn cp trunk branches/VFS-XXX >>>>>>>> $ cd branches/VFS-XXX >>>>>>>> # Set the proper versions >>>>>>>> $ mvn release:prepare >>>>>>> >>>>>>> We use a tag not a branch, but perhaps that is what the release plugin >>>>> does. >>>>>>> In which case I assume the branch is taken to avoid mangling trunk? >>>>>> >>>>>> release:prepare doesn't do the tagging (this is what release:perform >>>>>> does). All it's really doing are some pre-condition checks and version >>>>>> updates. TBQH, I don't have any idea how the maven-release-plugin and >>>>>> SVN are remotely useful for the ASF's vote-then-promote process. >>>>>> >>>>>> That said, it's ok if I don't get it. This is what worked for me and I'm >>>>>> happy with it. If there's something obvious I could have done >>>>>> differently, great. >>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> # Or just set it to your JDK6 installation -- this works on OSX >>>>>>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6) >>>>>>>> >>>>>>>> # Where ${asf.username} for me is "elserj" >>>>>>>> $ mvn clean package -Duser.name=${asf.username} >>>>>>> >>>>>>> No need to use package if using CP40 >>>>>> >>>>>> What are you using instead of `package` to build the code... >>>>>> >>>>>>> >>>>>>>> # Set back to 1.7 because my 1.6 installation has trouble deploying to >>>>> nexus >>>>>>>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7) >>>>>>> >>>>>>> So does mine; in which case use -Pjava-1.6 below. >>>>>>> >>>>>>>> $ mvn deploy -Prelease -Duser.name=${asf.username} >>>>>>>> >>>>>>>> # This is what could be consolidated via one invocation of `mvn site` >>>>>>>> $ mvn site:site site:stage >>>>>>>> >>>>>>>> # Move back to the root SVN repo >>>>>>>> $ cd ../.. >>>>>>>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN >>>>>>> >>>>>>> Isn't that what the release plugin does? >>>>>>> >>>>>>> You might find >>>>>>> >>>>>>> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh >>>>>>> >>>>>>> easier to use - it does it all for you without needing to create a >>>>>>> temporary branch. >>>>>> >>>>>> Cool. I didn't find these from the generic commons release document. >>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Things not covered above: >>>>>>>> >>>>>>>> * Copying artifacts (tarballs/zips, xsums, and sigs) into >>>>>>>> dist.a.o/dev/commons/... (building md5/sha1 files) >>>>>>>> * Closing staging repo in Nexus >>>>>>> >>>>>>> That can be done using Nexus2DistDev.sh >>>>>> >>>>>> Again, great. It would have been good to know about these beforehand. >>>>>> >>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Some things that could still be improved that I didn't fix: >>>>>>>> >>>>>>>> * Artifacts in dist/target are renamed when they're >>>>> installed/deployed, but >>>>>>>> not in the local directory. Should do a rename of the file on disk so >>>>> that >>>>>>>> what is on the RM's computer matches what is in their m2 repo and ASF >>>>> nexus. >>>>>>> >>>>>>> Or ignore the local copies and use Nexus2DistDev.sh which copies the >>>>>>> bin/src artifacts from Nexus and deploys to dist/dev and can remove >>>>>>> them from Nexus before closing the staging repo. >>>>>>> >>>>>>> AFAIK only the deploy directory (i.e. Nexus) has the hashes. >>>>>>> >>>>>>>> * `mvn site` which invokes site:site and site:stage automatically >>>>> (which >>>>>>>> would make for a more natural build process -- `mvn deploy` would >>>>> build the >>>>>>>> site automatically) >>>>>>> >>>>>>> I don't follow that. >>>>>> >>>>>> `mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site` >>>>>> and `mvn site:stage` are invoking executions on the maven-site-plugin. >>>>>> These are two distinct kinds of actions. We can configure the >>>>>> maven-site-plugin (and/or other necessary tasks) to run at the 'site' >>>>>> lifecycle phase for a more 'natural' process. >>>>>> >>>>>>> >>>>>>>> Again, for now, this is just for my benefit. When this is all over, >>>>> I'll try >>>>>>>> to add this all to the website. Please point out anything >>>>> wrong/missing. >>>>>>>> Thanks. >>>>>>>> >>>>>>>> - Josh >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>> <mailto:dev-unsubscr...@commons.apache.org> >>> <mailto:dev-unsubscr...@commons.apache.org >>> <mailto:dev-unsubscr...@commons.apache.org>> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> <mailto:dev-h...@commons.apache.org> <mailto:dev-h...@commons.apache.org >>> <mailto:dev-h...@commons.apache.org>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > <mailto:dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > <mailto:dev-h...@commons.apache.org>
