On Mon, Dec 7, 2009 at 10:00 AM, Les Hazlewood <[email protected]> wrote: > Another question: > Should we focus on one or two release candidates first? > That is, 1.0-RC1 < 1.0-RC2 < 1.0.0 (a final release)
There are a few strategies regarding this that are currently in use at Apache. The simplest is doing blind releases without RCs, then simply communicating major issues and abandoning the releases if issues were found during ro right after the release. RC is a like blind release but the version already communicating that it is not fully tested. The latest Maven way is doing staged releases - that is, the release is done as normal but deployed to a staging repository (Nexus can serve as one). You can then advertise the staging repo to a subset of users, and if everything looks good, the staged release can be promoted to a public release (without re-building binaries). Tapestry is attempting to do staged releases for the first time for their next release. Maven (the project) itself is doing both RCs and staged releases (of RCs). As far as I know, not too many other Apache projects uses staged releases yet, so we could wait on that and learn from others. The right solution depends on the complexity of the codebase and how much confidence you have on your test suite coverage and release process. Given that we've had a long and large exposure to 1.0-SNAPSHOTs (I'd assume many Shiro users are using the snapshots), I'd be inclined to keep it simple and start with blind releases and see how it goes. We can always improve the process later. If 1.0.0 goes bad for some reason, we can follow-up with 1.0.1 from the branch immediately. Just my thoughts on the topic - I'm not strongly in favor or against any approach. Kalle > On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen > <[email protected]> wrote: >> On that note, I think we should release 1.0.0. Current Maven >> versioning scheme works "best" with x.x.x numbering (see >> http://mojo.codehaus.org/versions-maven-plugin/version-rules.html). >> It'd also would make sensible to then reserve the incremental version >> (the last component) for bug fixes and allow using minor versions for >> new (compatible) feature releases. In essence, after releasing 1.0.0, >> we'd prepare the trunk for development of 1.1.0 and create 1.0.x >> branch for bug fixes and continue feature development, bug fixes etc. >> in the trunk until we identify a feature set we don't want to or won't >> make it to the next release, at which time we'd pull a 1.1x branch and >> update the trunk for development of 1.2.x (or even 2.0.x). >> >> Kalle >> >> >> On Mon, Dec 7, 2009 at 7:44 AM, Les Hazlewood <[email protected]> wrote: >>> I think most people in the Shiro community would agree that we're long >>> overdue for our first release ;) >>> >>> So, to that end, and unless anyone objects, I'm going to take a crack >>> at tagging only what I feel are the most important issues that >>> absolutely must be in to 1.0. When I'm done with that, I'd like to >>> post to this list again to allow people the opportunity to speak-up if >>> they see something that they think should be included but I missed. >>> >>> I'm doing this to help us get a little focus on what should concretely >>> define our first release, and to get it out as soon as possible from >>> now. Just my opinion, but I think it'd be great if we can finish all >>> the 1.0 issues (if not actually release) by 1 January. >>> >>> Please let me know if anyone does not agree with this, otherwise, I'll >>> get started as soon as possible organizing the existing issues. >>> >>> Thanks, >>> >>> Les >>> >> >
