In an attempt to raise quality and reduce/eliminate regressions in the core releases, we are experimenting with a new release process. The old process had a few informal staged builds followed by one or more official staged builds that where voted on. Clearly this didn't attract enough testing prior to the official release to identify regressions or other major issues.
The new process we are using for the 2.0.9 release is to cut actual release candidate (RC-XXX) releases. These are released with the normal release process so it generates a tag, but do not get sync'd to central. We have gone through several RCs[1] as we tested on the dev@ list. The next step is to open it up to the user list for fix validation and regression identification. This is really the first time we've followed such a process so we'll have to see how it pans out. Here are the "operating parameters" for this test: * The goal of the RCs are to stabilize the release and any changes at this point naturally risks further regressions. Therefore, the list of fixes for 2.0.9 is locked. We will not be including any more fixes at this point unless it meets the requirements laid out below. This means please don't reply with "could you just include xyz". * The issues we are looking to identify and fix are those where it can be shown to work with 2.0.8, but not with 2.0.9-RCxxx. These issues we will almost certainly fix. Our goal is to fix ALL regressions identified between 2.0.8 and 2.0.9, but naturally we need to weigh the severity of the issue along with the exposure against the complexity and risk of further regressions by fixing it. * If any of the issues that are marked as fixed for 2.0.9 are found to not be fixed, then we are interested in this as well, but more likely than not the fix will be rolled back and rescheduled for 2.0.10. Naturally the importance of the issue has bearing in how this will be handled. * If we can receive a sample project or IT[2] showing the issue, then it increases the likelihood of a quick fix and turnaround of the RC exponentially, both for regressions and for "not fixed" issues in 2.0.9 * Please report any regressions found between earlier versions of 2.0.x and 2.0.9 as they will be prioritized for 2.0.10 along with anything rolled back / not fixed from 2.0.9 * We will continue to iterate through this process until we feel that the release is ready to go. User list input will have a large factor in making this decision. That said, the quality of the 2.0.9 release will depend on the level of involvement from the entire community to test, reproduce and report issues identified. * Please file a Jira[3] for anything you find, and then reply to the RC thread with the details and issue number so that others may see and reduce duplicate reports. We will be watching Jira closely for reports with 2.0.9 in the affected version. * Once a release is ready, we will rebuild and restage the code from the most recent RC for a formal vote. This will produce the official "2.0.9" release. The list of issues fixed for this release can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13801&styleName =Html&projectId=10500&Create=Create Some notable changes are: * Plugin versions are locked in the superpom. (MNG-3395) You can see the locked versions here: http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/ma ven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml * In most cases they are locked to the currently available plugin to avoid suddenly downgrading users that haven't locked their own versions (still the best practice). * Webdav is included in the core, meaning you can deploy:deploy-file without a pom to include the extension (if you use webdav obviously) (MNG-2664) * New syntax for mirror definitions. Details here: MNG-3461 * Introduction of Import scope: (MNG-3220) http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html#Importing_Dependencies The binaries for this RC can be found here: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/ (naturally take the highest RC number deployed as it will change when we iterate) [1] Previous RC threads: http://www.nabble.com/-Pre-Vote--release-maven-2.0.9-td16124759s177.html http://www.nabble.com/-pre-vote-take-3--2.0.9-RC3-td16314473s177.html http://www.nabble.com/-2.0.9-RC4--td16344067s177.html http://www.nabble.com/-2.0.9-RC5--td16365465s177.html#a16365465 [2] Creating a Core IT: http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test [3] http://jira.codehaus.org/browse/MNG Thanks, The Maven Team
