cvs commit: jakarta-struts/doc releases.xml
husted 2004/01/13 05:18:06 Modified:doc releases.xml Log: Add @author tag clarification. Other tweaks. Revision ChangesPath 1.5 +12 -7 jakarta-struts/doc/releases.xml Index: releases.xml === RCS file: /home/cvs/jakarta-struts/doc/releases.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- releases.xml 28 Nov 2003 17:33:30 - 1.4 +++ releases.xml 13 Jan 2004 13:18:06 - 1.5 @@ -172,8 +172,9 @@ /li li -Set editors to replace tabs with spaces, and do not trim trailing -spaces. +Set editors to replace tabs with spaces and do not trim trailing +spaces. Tabs confound the CVS email alerts. Trimming trailing spaces +creates unnecessary changes. /li li @@ -189,7 +190,10 @@ Use code:FIXME:/code and code:TODO:/code tokens to mark follow up notes in code. You may also include your Apache username and the date. -code:FIXME: we need to do this sometime (husted 2002-11-14)/code +/li + +li +Omit code@author/code tags. /li li @@ -206,7 +210,7 @@ /li li -Please do your best to provide high-quality JavaDocs for all source code +Please do your best to provide high-quality Javadocs for all source code elements. Package overviews (aka Developer Guides) are also encouraged. /li @@ -214,7 +218,7 @@ li When working on a bugfix, please first write a a href=http://www.junit.org;JUnit/a test that proves the bug exists, -and then use the test to prove the bug is fixed. =:0) +and then use the test to prove the bug is fixed. =:0) /li li @@ -228,8 +232,9 @@ li As files are updated from year to year, the copyright on each file should be extended to include the current year. -You do not need to change the copyright year unless you change the file. -Every source file should include the current Apache License and copyright. +bYou do not need to change the copyright year unless you change the file./b +Every source file should include the ASF copyright notice and current +Apache License and copyright. /li li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc releases.xml
husted 2004/01/13 05:19:48 Modified:doc releases.xml Log: Tidy XML markup (-i -m -wrap 0 -xml). No content changes Revision ChangesPath 1.6 +104 -270 jakarta-struts/doc/releases.xml Index: releases.xml === RCS file: /home/cvs/jakarta-struts/doc/releases.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- releases.xml 13 Jan 2004 13:18:06 - 1.5 +++ releases.xml 13 Jan 2004 13:19:48 - 1.6 @@ -1,283 +1,117 @@ ?xml version=1.0? document url=./releases.xml - -!-- -// 78 --- - -properties + !-- + // 78 + -- + properties titleRelease Guidelines - The Apache Struts Web Application Framework/title authorTed Husted/author -/properties - -body + /properties + body section href=status name=Release Guidelines - -p -This document describes the Struts a href=#Releasesrelease process/a and our a href=#Codingcoding -conventions/a. Both stable and development releases are a href=acquiring.htmlavailable for download/a. -/p - + pThis document describes the Struts + a href=#Releasesrelease process/aand our + a href=#Codingcoding conventions/a. Both stable and development releases are + a href=acquiring.htmlavailable for download/a./p /section - section href=Releases name=Release Guidelines - -p -A a href=http://jakarta.apache.org/commons/versioning.html;point release/a -should be made before and after any product change that is not a fully-compatible change -(see link). This includes moving a dependency from an internal package to an external product, -including products distributed through the Jakarta Commons. -We should place any fully-compatible changes in the hands of the community -before starting on a change that is only interface or external-interface compatible. -/p -p -A fully-compatible point release does not always need a preview beta or milestone release. -If appropriate, a Release Candidate can be cut, uploaded to the Release Manager's home directory -on cvs.apache.org (~/public_html), and voted to be released to the general public from there. -/p - -p -Any release should follow the same general process used by the Jakarta Commons -and the Apache HTTP Server project. -/p - -ul -li - a href=http://jakarta.apache.org/commons/releases/;Releasing Common Components/a -/li -li -a href=http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases;Signing a release version/a -ul -li -smallThe MD5 tool is installed on daedalus, and you can create the digests for Struts releases -there./small -/li -/ul -/li -li -a href=http://httpd.apache.org/dev/release.html;Apache HTTPD Server Release Guidelines/a -/li -/ul - -p -Additional remarks: -/p - -ul -li -The release process can seem daunting when you review it for the first time. -But, essentially, it breaks down into three phases of just a few steps each: -ul -liBuilding - Bugzilla, dependencies, release notes, JAR manifest, licenses, copyrights, and build -(using the release target)./li -liTesting - JUnit, Cactus, web apps (for all supported containers). /li -liDistributing - Checksum, sign, mirror, release, update Struts site, update Jakarta site, -announce./li -/ul -/li -li -Our dependencies on external JARs (including Commons JARs) should -be in line with our own release status. -Our nightly build can be dependant on another nightly build. -Our beta can be dependant on another beta, -but should avoid a dependance on a nightly build. -Our release candidate can have a dependance on another RC, -but should not have a dependance on a beta (and certainly strongnot/strong a nightly build). -Our final release can only have dependencies on other final releases. -/li -li
cvs commit: jakarta-struts/doc releases.xml
husted 2003/11/28 09:33:30 Modified:doc releases.xml Log: Add note to alert PMC. Revision ChangesPath 1.4 +8 -6 jakarta-struts/doc/releases.xml Index: releases.xml === RCS file: /home/cvs/jakarta-struts/doc/releases.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- releases.xml 11 Sep 2003 23:08:12 - 1.3 +++ releases.xml 28 Nov 2003 17:33:30 - 1.4 @@ -65,11 +65,6 @@ ul li -Remember to update the a href=news/index.htmlStatus section of the News page/a when cutting any -milestone. -For a final release, also update the /doc/project.xml with the current release number. -/li -li The release process can seem daunting when you review it for the first time. But, essentially, it breaks down into three phases of just a few steps each: ul @@ -105,7 +100,7 @@ to take advantage of all available compiler enhancements. /li li -Before building the final release, run the JUnit and Cactus tests using the same +Before building the release, run the JUnit and Cactus tests using the same configuration used that will be used to build the Release distribution. /li li @@ -113,6 +108,13 @@ Before uploading the release, extract the sample web applications and deploy the WARs under each of the supported containers. Play test each application under each container to be sure they operate nominally. +/li +li +Be sure to copy the [EMAIL PROTECTED] list on any release announcement. +/li +li +Remember to update the a href=status.htmlStatus section of the Roadmap page/a +once a release is available. /li li By the way, the nightly builds are being created on a machine of Craig McClanahan's. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc releases.xml acquiring.xml
husted 2003/09/11 16:08:12 Modified:doc releases.xml acquiring.xml Log: + Routine updates. Revision ChangesPath 1.3 +9 -5 jakarta-struts/doc/releases.xml Index: releases.xml === RCS file: /home/cvs/jakarta-struts/doc/releases.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- releases.xml 9 Sep 2003 17:49:21 - 1.2 +++ releases.xml 11 Sep 2003 23:08:12 - 1.3 @@ -15,7 +15,7 @@ p This document describes the Struts a href=#Releasesrelease process/a and our a href=#Codingcoding -conventions/a. +conventions/a. Both stable and development releases are a href=acquiring.htmlavailable for download/a. /p /section @@ -49,7 +49,8 @@ a href=http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases;Signing a release version/a ul li -smallThe MD5 tool is installed on daedalus, and you can create the digests for Struts releases there./small +smallThe MD5 tool is installed on daedalus, and you can create the digests for Struts releases +there./small /li /ul /li @@ -64,16 +65,19 @@ ul li -Remember to update the a href=news/index.htmlStatus section of the News page/a when cutting any milestone. +Remember to update the a href=news/index.htmlStatus section of the News page/a when cutting any +milestone. For a final release, also update the /doc/project.xml with the current release number. /li li The release process can seem daunting when you review it for the first time. But, essentially, it breaks down into three phases of just a few steps each: ul -liBuilding - Bugzilla, dependencies, release notes, JAR manifest, licenses, copyrights, and build (using the release target)./li +liBuilding - Bugzilla, dependencies, release notes, JAR manifest, licenses, copyrights, and build +(using the release target)./li liTesting - JUnit, Cactus, web apps (for all supported containers). /li -liDistributing - Checksum, sign, mirror, release, update Struts site, update Jakarta site, announce./li +liDistributing - Checksum, sign, mirror, release, update Struts site, update Jakarta site, +announce./li /ul /li li 1.15 +2 -2 jakarta-struts/doc/acquiring.xml Index: acquiring.xml === RCS file: /home/cvs/jakarta-struts/doc/acquiring.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- acquiring.xml 9 Sep 2003 17:49:21 - 1.14 +++ acquiring.xml 11 Sep 2003 23:08:12 - 1.15 @@ -77,13 +77,13 @@ li Nightly builds - Download the binary distributions from the - a href=http://jakarta.apache.org/builds/jakarta-struts/nightly; + a href=http://cvs.apache.org/builds/jakarta-struts/nightly; Struts nightly builds directory/a. /li li Nightly builds - Download the source distributions from the -a href=http://jakarta.apache.org/builds/jakarta-struts/nightly/src; +a href=http://cvs.apache.org/builds/jakarta-struts/nightly/src; Struts nightly build source directory/a. /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc releases.xml
husted 2003/08/29 09:49:28 Added: doc releases.xml Log: + Create releases page from lower portion of status page. Revision ChangesPath 1.1 jakarta-struts/doc/releases.xml Index: releases.xml === ?xml version=1.0? document url=./releases.xml !-- // 78 -- properties titleRelease Guidelines - The Apache Struts Web Application Framework/title authorTed Husted/author /properties body chapter href=status name=Release Guidelines section href=status name=Release Guidelines p This document describes the Struts a href=#Releasesrelease process/a and our a href=#Codingcoding conventions/a. /p /section section href=Releases name=Release Guidelines p A a href=http://jakarta.apache.org/commons/versioning.html;point release/a should be made before and after any product change that is not a fully-compatible change (see link). This includes moving a dependency from an internal package to an external product, including products distributed through the Jakarta Commons. We should place any fully-compatible changes in the hands of the community before starting on a change that is only interface or external-interface compatible. /p p A fully-compatible point release does not always need a preview beta or milestone release. If appropriate, a Release Candidate can be cut, uploaded to the Release Manager's home directory on cvs.apache.org (~/public_html), and voted to be released to the general public from there. /p p Any release should follow the same general process used by the Jakarta Commons and the Apache HTTP Server project. /p ul li a href=http://jakarta.apache.org/commons/releases/;Releasing Common Components/a /li li a href=http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases;Signing a release version/a ul li smallThe MD5 tool is installed on daedalus, and you can create the digests for Struts releases there./small /li /ul /li li a href=http://httpd.apache.org/dev/release.html;Apache HTTPD Server Release Guidelines/a /li /ul p Additional remarks: /p ul li Remember to update the a href=news/index.htmlStatus section of the News page/a when cutting any milestone. For a final release, also update the /doc/project.xml with the current release number. /li li The release process can seem daunting when you review it for the first time. But, essentially, it breaks down into three phases of just a few steps each: ul liBuilding - Bugzilla, dependencies, release notes, JAR manifest, licenses, copyrights, and build (using the release target)./li liTesting - JUnit, Cactus, web apps (for all supported containers). /li liDistributing - Checksum, sign, mirror, release, update Struts site, update Jakarta site, announce./li /ul /li li Our dependencies on external JARs (including Commons JARs) should be in line with our own release status. Our nightly build can be dependant on another nightly build. Our beta can be dependant on another beta, but should avoid a dependance on a nightly build. Our release candidate can have a dependance on another RC, but should not have a dependance on a beta (and certainly bnot/b a nightly build). Our final release can only have dependencies on other final releases. /li li Use your own discretion as to detail needed by the Release Notes. A high-level description of the changes is more important than providing uninterpreted detail. At a minimum, new features and deprecations should be summarized, since these are commonly asked questions. Ideally, the release notes should be maintained continuously for the nightly build so that we do not need to quickly assembled them on the eve of a Release. /li li Test building the
