Hello Josh, It's really great how much effort you're putting into this release. Thank you for that!
Benedikt sebb <seb...@gmail.com> schrieb am Do., 5. Mai 2016 um 09:57 Uhr: > On 5 May 2016 at 05:49, Josh Elser <els...@apache.org> wrote: > > > > > > 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. > > They are brand new, and possibly still needing some tweaks. > They don't work wit Git. > > >> 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. > > OK > > > 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. > > I agree. > It's just wrong that trunk is updated before the release succeeds. > However using a temporary branch would solve that. > > > 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... > > mvn deploy > > >> > >>> # 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. > > They are very new. > > >>> -- > >>> > >>> 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. > > They did not exist then... > > >> > >>> -- > >>> > >>> 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. > > > > I see. > > I meant I did not see why 'mvn deploy ' would/should create the site. > > >> > >>> 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 > >
