Re: Releasing shale master pom
On Dec 19, 2006, at 10:46 PM, Craig McClanahan wrote: The updater should be our long term direction, unless/until the Maven release plugin does all the stuff we need for staging votes. What's missing in the release plugin? Just that there's no way to stage a release? Do we use the release plugin to publish a release? Greg
Re: Releasing shale master pom
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: What's missing in the release plugin? Just that there's no way to stage a release? Do we use the release plugin to publish a release? Neither Struts nor Shale has so far used the release plugin at all. The default distributionManagement repository that we inherit from the org.apache:apache pom actually points to the repo that gets rsynced to Maven central, so there was no staging, and no way to vote on an actual artifact before a release. Now we have distributionManagementrepository pointed at a staging repo (there's nothing special about the location, it could be any directory reachable via scp) so we can vote in advance of actually publishing things to the Maven central repo. What's missing, then, is a way of merging the staged artifacts into the rsynced repo. The jars can just be copied over, but the info in the repository metadata xml files needs to be merged together. That code now exists, but it's still being tested. The whole Maven release process is under discussion now by a group including Maven developers and users, people working on Incubator projects and ASF infrastructure folks. -- Wendy
Re: Releasing shale master pom
On 12/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ * I like the habit I've seen Rahul and others do in Commons, of adding contributor entries for those who have posted patches. A quick scan of our issues might be useful. snap/ This becomes hard after the fact. If we decide to do this (I think we should), we must continually update the contributors section in the future. I came up with a starter set after a few minutes looking around (at the end of the email). If we're doing this for master pom v2, we need everyone to jump in now (i.e. within a day or two) and complete the starter set by reviewing their own commits and making necessary additions. Note that this leaves out any Struts folks (except some that are pulled in by some issue), so someone should review that as well. Then there is the question of ordering (alphabetical, chronology of contribution etc. can be criteria for sorting). I like chronology (so the order would be the same as below -- then new contributors just get added to the end). The bits in bracket are for reference only and obviously won't be in the pom. So, again, please complete this. -Rahul Duncan Mills (SHALE-2) Ronald Holshausen (SHALE-3) Manfred Klug (SHALE-4) David DeWolf (SHALE-27) Keijo Numes (SHALE-43) Shane Bryzak (SHALE-45) Ted Husted (SHALE-76) Dennis Bryne (SHALE-78) Richard Wallace (SHALE-84) Bill Young (SHALE-106) Alexandre Poitras (SHALE-114) Hubert Rabago (SHALE-131) David Thielen (SHALE-148) Ed Burns (SHALE-178) Ingo Dueppe (SHALE-190) Jack Cheng (SHALE-203) Niall Pemberton (SHALE-207, wiki reorg) Marcello Teodori (SHALE-232) Reind (SHALE-247) Mike Kienenberger (SHALE-251) Andrew Gilette (SHALE-255) Ryan Lubke (SHALE-270) Shinsuke Sugaya (SHALE-282) Mario Ivankovits (SHALE-296) Hermod Opstvedt (SHALE-324) Mike Meessen (SHALE-327) Luis Parravicini (SHALE-370) Ryan Wynn (http://wiki.apache.org/shale/ReusableClayJars) Rene Zanner (wiki documentation) Adrian Mitev (wiki documentation) Simon Kitching (wiki documentation) Craig
Releasing shale master pom
Figure we should get that going while we wrap up on 1.0.4 code, otherwise a 72 hour buffer (at the least). I'm not aware of any pending changes ATM, but if you have any, please go ahead. Some procedural bits, yell if incorrect: * I can't find the v1 tag (probably somewhere is Struts land, not sure) but the v2 tag will be at maven/tags * 'mvn deploy' master pom to staging repo (which should be the repo of choice once the snapshot marker gets removed) and when vote passes do a *nix 'cp' on people of the 2/ directory and maven-metadata.* from the staging repo to the m2-ibiblio-repo. Wanted to confirm that the metadata copy, in particular, is OK. -Rahul
Re: Releasing shale master pom
On 12/19/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Figure we should get that going while we wrap up on 1.0.4 code, otherwise a 72 hour buffer (at the least). I'm not aware of any pending changes ATM, but if you have any, please go ahead. Some procedural bits, yell if incorrect: * I can't find the v1 tag (probably somewhere is Struts land, not sure) but the v2 tag will be at maven/tags I suspect I forgot to tag it explicitly, but from svn log it looks like r430659 did the deed. * 'mvn deploy' master pom to staging repo (which should be the repo of choice once the snapshot marker gets removed) and when vote passes do a *nix 'cp' on people of the 2/ directory and maven-metadata.* from the staging repo to the m2-ibiblio-repo. Wanted to confirm that the metadata copy, in particular, is OK. For some reason I went through more work than this last time ... but I suspect it's because we had not formalized our staging process, and I was using my ~craigmcc directory. This sounds right (unless, as Wendy says, you want to live dangerously and try the repository updater :-). The updater should be our long term direction, unless/until the Maven release plugin does all the stuff we need for staging votes. -Rahul A couple of notes on the master POM itself (as of r488876): * Is org.apache:apache:3 still the right parent for shale-parent? It should be unless they've published a new top level one. * I like the habit I've seen Rahul and others do in Commons, of adding contributor entries for those who have posted patches. A quick scan of our issues might be useful. Craig
