You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Brian E. Fox" <br...@reply.infinity.nu> on 2008/03/31 23:25:47 UTC
2.0.9 Release Candidate
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
Re: 2.0.9 Release Candidate
Posted by "David J. M. Karlsen" <da...@davidkarlsen.com>.
Brian E. Fox skrev:
> Having to do a formal vote and release is not agile enough, we'd be
> doing RCs for decades. Hopefully the users on the list are interested in
> quality and forward compatibility of their builds to grab the RC and
> give it a whirl. As I said, the quality is now a community effort and
> entirely dependent on the level of user interaction with the RCs.
>
RCs seems a very good way to go to me.
This gives the most active maven users a chance to do a QA on a certain
rev before it's released out to the masses - and will probably help on
the stability and end-quality.
RCs are also easier to track and test for ppl who do not want to build
trunk self - and probably less of a moving target than the earlier seen
approaches - this again increases the chance that it in fact will be
tested thorughly.
My $.05
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: 2.0.9 Release Candidate
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Having to do a formal vote and release is not agile enough, we'd be
doing RCs for decades. Hopefully the users on the list are interested in
quality and forward compatibility of their builds to grab the RC and
give it a whirl. As I said, the quality is now a community effort and
entirely dependent on the level of user interaction with the RCs.
-----Original Message-----
From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
On Behalf Of Paul Benedict
Sent: Monday, March 31, 2008 11:58 PM
To: Maven Users List
Subject: Re: 2.0.9 Release Candidate
Brian,
I hope the release process can be refined to allow substantial usage of
the
RC builds by syncing with the central repo. Since Apache requires a
"release" to have binding votes, you could publish them for a week or
two
and collect feedback rather than rapidly producing RC after RC. Maybe
you
want to use RC as a patch version or go one level further (2.0.8.1,
etc.)?
In any event, the downside of not publishing a build is that you can't
call
it a "release" and get the widespreader usage than the die-hard Maven
watchers.
Paul
On Mon, Mar 31, 2008 at 4:25 PM, Brian E. Fox <br...@reply.infinity.nu>
wrote:
> 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.
>
>
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: 2.0.9 Release Candidate
Posted by Paul Benedict <pb...@apache.org>.
Brian,
I hope the release process can be refined to allow substantial usage of the
RC builds by syncing with the central repo. Since Apache requires a
"release" to have binding votes, you could publish them for a week or two
and collect feedback rather than rapidly producing RC after RC. Maybe you
want to use RC as a patch version or go one level further (2.0.8.1, etc.)?
In any event, the downside of not publishing a build is that you can't call
it a "release" and get the widespreader usage than the die-hard Maven
watchers.
Paul
On Mon, Mar 31, 2008 at 4:25 PM, Brian E. Fox <br...@reply.infinity.nu>
wrote:
> 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.
>
>
Paul