Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (herse.apache.org: domain of ted.husted@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth;
        b=swtQ4tyjxMuhWBYkxN6t1R75OoWC/CJ7H2IHXcUkbcFPusySHuXnVJSiqWKeVC5eESS6muOoJvVQq72H7z80tMwOQcofPN/VMiqKWdoi7LSVhF4GxSjtBrlb+5dsBlNnQaPRtVvJfuyO8nBroT01M4ZWeuVWFG4Y0upNNj8aUzg=
Message-ID: <8b3ce3790704070517o326802c1w2e27cf12327876bf@mail.gmail.com>
Date: Sat, 7 Apr 2007 08:17:48 -0400
From: "Ted Husted" <husted@apache.org>
Sender: ted.husted@gmail.com
To: "Struts Developers List" <dev@struts.apache.org>
Subject: [S2] Releases, How to Help
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm told that there will be a new XWork out soon, and Struts 2.0.8 will follow.

In the meantime, there are a number of ways people can help get the
releases out quickly.

* Update the documentation.

As new features are added or enhanced, it's helpful to keep the
documentation in synch. The volunteers making the commits don't always
have the time or energy left to update the documentation too. Sharing
the wealth should also mean sharing the work. Don't hesitate to reduce
a commit log to a new paragraph or page in the documentation, or add a
new snippet reference to the JavaDoc. Ditto goes for posts to the
mailing list. If someone answers your question, try to update the
documentation with the answer. Remember, editing rights are available
to anyone who files a CLA.

  * http://struts.apache.org/2.x/docs/editing-the-documentation.html

* Update the release notes too.

Since we use issue-driven-development, we can use the JIRA release
notes to detail every change. But, it's still helpful to have a
high-level summary of the changes. As commits happen and tickets
close, everyone is welcome to make any relevent changes to the release
notes page in Confluence. To get there, follow the link to the
"development site" and then to the "release notes".

* Review the patches.

A committer has to apply a patch to the repository, but it's helpful
if other volunteers review and apply patches to their own working copy
too. A "Works for me" helps to prioritize which patches to apply
first.

* Try the build.

Releases are cumulative. Trying the working build before it is tagged
helps identify showstoppers before they happen. If you can take the
time, deploy your application against the working build in your
development environment. The project tradition is that milestones
within minor release series should be binary compatible with the prior
milestone release.

* Vote on the test build.

The quickest way to get a test build to beta is for other people to
try it and vote "works for me". If we have three committers voting,
there may be a tendency to try the build as a beta first. If we have
three committers and a dozen other developers voting, then it's easier
to go straight to GA.

TIA, Ted
<http://husted.com/ted/blog/>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org