cvs commit: jakarta-commons/commons-build/xdocs/releases prepare.xml
bayard 2004/05/31 16:06:55 Modified:commons-build/xdocs/releases prepare.xml Log: RESULT email needs to list voters and their votes Revision ChangesPath 1.11 +2 -2 jakarta-commons/commons-build/xdocs/releases/prepare.xml Index: prepare.xml === RCS file: /home/cvs/jakarta-commons/commons-build/xdocs/releases/prepare.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- prepare.xml 29 May 2004 21:29:42 - 1.10 +++ prepare.xml 31 May 2004 23:06:55 - 1.11 @@ -180,7 +180,6 @@ /p /subsection subsection name='[VOTE] Release foo 1.0' -!-- Only cc PMC in on the RESULT. Votes require 3 +1s and no -1s. After a period of time, 3 days to a week, send a RESULT email -- p Once the release candidate has been created and uploaded, now it's time to propose the release VOTE. /p @@ -197,7 +196,8 @@ p Once a vote is successful, post a code[RESULT] Release foo 1.0/code email to strong[EMAIL PROTECTED]/strong as a reply to the original posting, -and cc strong[EMAIL PROTECTED]/strong. +and cc strong[EMAIL PROTECTED]/strong. This email should contain a summary +of the voters/votes that were cast. /p /subsection subsection name='Final Preparations' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs/releases prepare.xml
bayard 2004/05/29 14:29:42 Modified:commons-build/xdocs/releases prepare.xml Log: various bits I came across while building common-io 1.0 Revision ChangesPath 1.10 +26 -5 jakarta-commons/commons-build/xdocs/releases/prepare.xml Index: prepare.xml === RCS file: /home/cvs/jakarta-commons/commons-build/xdocs/releases/prepare.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- prepare.xml 22 May 2004 00:11:50 - 1.9 +++ prepare.xml 29 May 2004 21:29:42 - 1.10 @@ -68,6 +68,7 @@ Implementation-Vendor: Apache Software Foundation Implementation-Version: 1.3 /pre +pIf building using Maven, this is done automatically. /p /subsection subsection name='Bugzilla' p @@ -81,7 +82,7 @@ /p /subsection subsection name='Release Notes' -p +p Different components have their own ways of creating release notes. Here's the hard way! /p @@ -91,8 +92,11 @@ Bugs fixed should be listed separately together with a short summary of the bug. A little time may be saved by checking the logs only for the source files. /p -p -Please remember to spell check the release notes. Please break lines at 80 characters. +p +Please remember to spell check the release notes. Please break lines at 80 characters. +/p +p +Maven users may wish to use the changes.xml changelog report. /p /subsection subsection name='Test Against Listed Dependencies' @@ -103,6 +107,12 @@ dependency issues should probably be raised on the commons-dev list. /p /subsection +subsection name='Ensure a good build.xml' +p +If using Maven, ensure that 'maven ant' has been run so a usable build.xml file exists, +and has the correct version. +/p +/subsection subsection name='Check the Apache License' p Check the a href=http://www.apache.org/licenses/;Apache Licenses/a page for current information. @@ -163,20 +173,31 @@ into the public folder em~/public_html/em in your home directory on codecvs.apache.org/code.) /p +p +Remember to put up the website that will be deployed when the disributions are released. You may +also want to show a unit-test code coverage report, using a tool such as Clover or jCoverage, +and the differences since the previous version, using a tool like JDiff. +/p /subsection subsection name='[VOTE] Release foo 1.0' +!-- Only cc PMC in on the RESULT. Votes require 3 +1s and no -1s. After a period of time, 3 days to a week, send a RESULT email -- p Once the release candidate has been created and uploaded, now it's time to propose the release VOTE. /p p -Post a code[VOTE] Release foo 1.0/code email to strong[EMAIL PROTECTED]/strong -and cc strong[EMAIL PROTECTED]/strong. This should contain a link to the release candidate. +Post a code[VOTE] Release foo 1.0/code email to strong[EMAIL PROTECTED]/strong. +This should contain a link to the release candidate. /p p As per the Commons Project charter, votes of committers on the particular package in question (as listed in the codeSTATUS.html/code) are binding. If the code[VOTE]/code is successful then continue. It is considered good practice to allow enough time for people to express their opinions. +/p +p +Once a vote is successful, post a code[RESULT] Release foo 1.0/code email to +strong[EMAIL PROTECTED]/strong as a reply to the original posting, +and cc strong[EMAIL PROTECTED]/strong. /p /subsection subsection name='Final Preparations' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs/releases prepare.xml
ggregory2004/05/21 17:11:50 Modified:commons-build/xdocs/releases prepare.xml Log: Update for Apache License 2.0 info. Revision ChangesPath 1.9 +35 -5 jakarta-commons/commons-build/xdocs/releases/prepare.xml Index: prepare.xml === RCS file: /home/cvs/jakarta-commons/commons-build/xdocs/releases/prepare.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- prepare.xml 13 May 2004 15:30:03 - 1.8 +++ prepare.xml 22 May 2004 00:11:50 - 1.9 @@ -103,12 +103,42 @@ dependency issues should probably be raised on the commons-dev list. /p /subsection -subsection name='Check LICENSE' +subsection name='Check the Apache License' p -Make sure that there is a strongcomplete/strong -Apache Software License at the top of each source file. The so-called emshort form/em -of the license has not been approved and should not be used. -/p +Check the a href=http://www.apache.org/licenses/;Apache Licenses/a page for current information. +/p +p +Developer documentation on how to apply the Apache License +can be found in a href=http://www.apache.org/dev/apply-license.html;Applying the Apache License, Version 2.0/a +/p +p +Some of the important items from the aforementioned documents: +/p +p +bDo I have to have a copy of the license in each source file?/b +/p +p +Only one full copy of the license is needed per distribution. Each source +file only needs to contain the boilerplate notice at: +/p +p +codea href=http://www.apache.org/licenses/LICENSE-2.0.html#apply;http://www.apache.org/licenses/LICENSE-2.0.html#apply/a/code +/p +p +bIn my current source files I have attribution notices for other works. +Do I put this in each source file now?/b +/p +p +No. The new license allows for a NOTICE file that contains such attribution +notices (including the Apache attribution notice). See +/p +p +codea href=http://www.apache.org/licenses/example-NOTICE.txt;http://www.apache.org/licenses/example-NOTICE.txt/a/code +/p +p +for an example that provides all of the notices applicable to the +httpd-2.0 distribution. +/p p Also check that the years in the copyright statement in the license in each source file and in the component codeLICENSE.txt/code have been updated appropriately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs/releases prepare.xml
yoavs 2004/05/13 08:30:04 Modified:commons-build/xdocs/releases prepare.xml Log: Fixed bad link URL. Revision ChangesPath 1.8 +1 -1 jakarta-commons/commons-build/xdocs/releases/prepare.xml Index: prepare.xml === RCS file: /home/cvs/jakarta-commons/commons-build/xdocs/releases/prepare.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- prepare.xml 13 May 2004 14:56:37 - 1.7 +++ prepare.xml 13 May 2004 15:30:03 - 1.8 @@ -50,7 +50,7 @@ subsection name='Update The Jar Manifest' p Each commons component release jar should contain a codeMANIFEST.MF/code conforming to the -a href='http://java.sun.com/j2se/1.5.0/docs/jar/jar.html'Sun Manifest Format/a. +a href='http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html'Sun Manifest Format/a. In additional, commons components should adhere to the a href='http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.html' Sun Package Versioning Standards/a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs/releases prepare.xml
yoavs 2004/05/13 07:56:37 Modified:commons-build/xdocs/releases prepare.xml Log: Fixed Sun links for Jar tool and Versioning spec. Revision ChangesPath 1.7 +2 -2 jakarta-commons/commons-build/xdocs/releases/prepare.xml Index: prepare.xml === RCS file: /home/cvs/jakarta-commons/commons-build/xdocs/releases/prepare.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- prepare.xml 1 Mar 2004 22:31:34 - 1.6 +++ prepare.xml 13 May 2004 14:56:37 - 1.7 @@ -50,9 +50,9 @@ subsection name='Update The Jar Manifest' p Each commons component release jar should contain a codeMANIFEST.MF/code conforming to the -a href='http://java.sun.com/products/jdk/1.2/docs/guide/jar/manifest.html'Sun Manifest Format/a. +a href='http://java.sun.com/j2se/1.5.0/docs/jar/jar.html'Sun Manifest Format/a. In additional, commons components should adhere to the -a href='http://java.sun.com/products/jdk/1.2/docs/guide/versioning/spec/VersioningSpecification.html#PackageVersioning' +a href='http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.html' Sun Package Versioning Standards/a /p p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
