On 5 May 2016 at 13:29, Benedikt Ritter <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 For additional commands, e-mail: dev-h...@commons.apache.org
