Very late, but I've been a tad busy in the new-parent department. Generally I agree with Phil's email. I don't really care though - I recognize that my main pain with Nexus is a) the experience to know not to trust magical systems & b) not being full of energy to follow yet another build system change. I'm sure Maven 3.0 will be coming and I'll have to find the time to look into that.
I've a bunch of JIRA plugins that are basically dead now because Atlassian moved to OpenSocial and I don't have the time/interest to read up on OpenSocial. This is the same - major shifts are costly and I'm now in the 'can't keep up'. My time is worth more to me than the novelty of the features :) Sucks to be me. What I do care about is releasing often. Which is farcical given how few times I've released. I want to release every month. Every week if possible. With minimal effort as I don't have the time to waste building releases for code that is fine enough. If that means pressing some magic button and Nexus takes care of things; fine. I'm loathe to read the 7 pages of "How to Release updated for Nexus", but I recognize that a lot of that is my own lacking. That said 97% of it is boring as it's really How to Release [the Nexus version] and not the 10 line page that its title implies it should be). [Side note; this is insane: http://maven.apache.org/guides/mini/guide-encryption.html - I vomit every time it's implied I should put passwords in the Maven settings file] End of opinion :) Hen On Tue, Mar 29, 2011 at 7:50 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > After another nightmare by an RM who has not cut a release in a > while, I think we need to do something. The documentation on the > Commons web pages describes a process that works. I suggest that we > standardize on that process, adding some simple automation scripts > that RMs can choose to use or not to use for the manual steps and > stop fussing with Nexus or the maven release plugin. I cut an RC > last night in 25 minutes (about 15 of which were spent waiting for > the [pool] tests to complete) and will likely spend about that same > amount of time deploying the artifacts to dist/ and what remains of > our simple, file-and-directory-based replication infrastructure to > get maven artifacts pushed to the maven repos. I do use a simple > shell script to manage invoking the maven commands and copying files > around to reduce the required time from, say an hour, to 25 > minutes. The script is in svn. > > I prefer the "manual" approach for the following reasons: > > 1. I know what it does. Exactly, every time. I know that exactly > the binaries that we vote on get deployed to dist/ and exactly the > committed tag is used to build everything. The process includes > local generation of artifacts that I can inspect and test locally > and verify sigs. I know at each step exactly what is being pushed > where. > > 2. I know that it works. Every time. No pom-tweaking, > plugin-munging or other half-success management required. > > 3. It has no commercial / proprietary dependencies. The scripts > are optional and are in any case, ASF-licensed, committed to svn. > > I know others have different opinions on this. It could be we need > to support both ways of cutting releases. I would ask, however, > that those arguing for the "automagical" approach take a hard look > at how many volunteer hours are being spent trying to get > maven/nexus to be a release manager and how comparatively little > time those of us who take the "manual" approach spend getting our > releases built and deployed. While I certainly can't claim to > produce perfect artifacts (much less code :), I will also point out > that the only major release quality problem that we have had > recently was the inadvertent release of a [net] version while > fiddling with the release plugin. I don't at all buy the argument > that the manual approach is "error-prone" as it allows more and > better opportunities for inspection by the RM and community at each > stage. > > Phil > > --------------------------------------------------------------------- > 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
