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

Reply via email to