struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <hus...@apache.org>
Subject [S2] Releases, How to Help
Date Sat, 07 Apr 2007 12:17:48 GMT
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


Mime
View raw message