This is a draft of the release plan for 1.7. I figure it's important to document this somewhere other than my grey cells.
Release types =========== The following define the various types of releases reference throughout this plan, in order of increasing stability. While there is no requirement to do any alpha or beta releases, we may choose to in an effort to get the code into the hands of potential users and testers much quicker. Nightly ------- Nightly builds are tarballs automatically generated with our current distribution scripts. They are neither tested nor signed, and may not even build, depending on the current state of trunk (or the designated branch). Nightly builds should be used with extreme care. Current nightly tarballs of trunk are available here: http://people.apache.org/~hwright/svn/nightly/ Alpha ----- Alpha releases have been tested and signed by the community, but are considered unstable. Persistent working copy and disk formats in an alpha release are expected to be "finalized"[1] are expected to remain the same through the final release. Alpha releases usually contain known issues, which are summarized in the release announcement. The signing requirements are somewhat relaxed for alpha releases (the signatures exist as a tamper-evidence, rather than a correctness-evidence). Beta ---- Beta releases improve upon the general stability of alpha releases, and contain protocols and APIs which are considered to be "finalized"[1]. Beta releases are tested and signed, but may also contain known issues, hopefully fewer than alpha releases. Any issues are summarized in the release announcement. Signing policies are similar to that of alpha releases. Release Candidate ----------------- Release candidates are just that: candidates for a final release. They are tested and signed, and should contain no known issues of sufficient severity.[2] Should no serious bugs be found during testing, a release candidate will become the final release. Final or Generally Available (GA) --------------------------------- The tarball which is released to the world as Subversion. Tested, signed and blessed by the community for wide-spread consumption. As stable as we can get it[2]. Timeline ======== None of the following actions have dates corresponding to them. Instead, we can progress between stages as dictated by the results of the previous stage, as well as the consensus of the community. (The notable exception is the customary 28-day minimum soak period during the release candidate stage.) Full release process details are available here: http://subversion.apache.org/docs/community-guide/releasing.html Events ------ Stabilize on-disk formats Start publishing frequent alpha releases Review APIs, protocols Start publishing frequent beta releases Branch 1.7.x Publish first RC / start soak Publish interim RCs, restarting soak as needed Publish final RC Publish Subversion 1.7.0 It looks like we might be fairly close to having on-disk formats stabilized, and hence rolling alphas. Prereleases may be fairly prolific, since I want to work the bugs out of the transition to ASF distribution infrastructure, and get fixes into the hands of users rapidly. If you've got comments or questions, let's hear 'em! -Hyrum [1] Of course, we reserve the right to change disk formats and APIs prior to the generally available release, and will include said caveat in the release announcements. The benefit of this guideline is having at least some sort of user and developer expectation. [2] No software is bug-free, and we will almost certainly have to make the painful choice between releasing soon with a bug, or releasing later with a bug-fix. The definition of "sufficient severity" is left as an exercise for the PMC.
