On Tue, Jun 1, 2010 at 4:42 PM, sebb <seb...@gmail.com> wrote: > On 01/06/2010, Les Hazlewood <lhazlew...@apache.org> wrote: >> Otherwise we assume the release would have been voted against. > The lack of a DISCLAIMER was reported as part of the vote. > I don't know why it was not considered blocking.
Either you vote or you don't, everything else is considered advisory, you know that. The release packages that most people in practice will use contain -incubating in the file name. I don't know what could be any more explicit. Anyhow, we'll add a file for the next release. >> Why isn't there a no-frills step-by-step, no room-for-error release >> checklist that podlings can follow to guarantee that all required >> criteria are met? It seems like such a checklist would be of the >> highest priority for the Incubator to ensure that personal >> interpretation is minimized or eliminated from the release process. Maven (the project) has super clear step-by-step instructions at http://maven.apache.org/developers/release/apache-release.html for releasing with Maven (kudos to Maven guys for that!) which I followed religiously. Maybe you could write another one for Maven-based podling releases but I'm not sure it's worth it. Most of the pain we (Shiro) experienced was with the website - these rules are really not clear and there's a million different competing technologies to put together a project website. Unless incubator starts dictating the technologies to use for a podling website (which I'd be strongly against), I don't see how one could write up a *simple* checklist. It's worth an effort to clarify the http://incubator.apache.org/guides/releasemanagement.html page though. Whatever the technology, I'd much rather improve something existing than whip up yet another semi-official Confluence page. Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
