On 12/15/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
<snip/>
Re: you guys tag teaming on RM for Shale ... +1! :-). The wiki has a bunch of notes (mostly from Wendy) that I basically followed last time. A couple of things to watch out for: * The shale-master pom should be upversioned and released separately first, so we don't have to depend on a snapshot version of it
<snap/> Yup, I'll get to this, have a question first (probably deserves a new thread -- in a few minutes).
* The parent pom has maven-javadoc-plugin and maven-source-plugin commented out for quicker development builds ... we'll want them for a release build. * There's a bunch of other commented out cruft that we might as well get rid of too.
<snip/> +1 to removing pom cruft (we can recover it from SVN history, and add back later if needed).
* The details of how we can stage the actual bits to be voted on are likely to be slightly different ... but the key principle is that we want to be able to examine the actual bits being proposed (i.e. with a 1.0.4 version number, not an RC suffix) for the actual vote. Rahul's getting used to this on Commons releases :-). * Don't forget to tag the repository
<snap/> Sounds like reasonable things to do :-) We even have a staging repo defined in the master pom (thanks Wendy) which we should use for this.
After the release, I'm also suggesting that we hold off on major changes to the repository until we talk about my earlier proposal to branch at this point and start working on 1.1 in the trunk, giving us the ability to do bugfix and/or security releases to the 1.0 branch without polluting it with new features. With SVN its easy to change our minds about whether the tag is under "tags" or "branches", but I'd like to see us formalize that decision before getting active again.
<snip/> OK by me. -Rahul
Craig
