Unable to render {include} The included page could not be found. Getting ReadyUseful ResourcesIncubator release best practice Release Reviewer Check List
Release Manager Release ProcessThis page borrows many of the commands from Raymond's release script but with a bit more explanation and a few extra useful commands. The commands here were taken from when release 1.1 RC3a was under preparation. Note that this document has been updated from experience gained with the SDO 1.1.1 release, which was the first release made after exiting incubation; as such, whilst the release names used in this document refer to an "incubating" version, the svn repository and the maven repository have been updated to the non incubating versions. It's also fair to say that it's unlikely that you will want to run all of these commands in sequence as you generally end up repeating sections as release preparation progresses. Call for releases(Note that the maven tuscany plugin will most likely need to be released in parallel with the Tuscany release) At some point someone in the community will call for a release based on the features and fixes that have been under development in the trunk. Typically the first stage in the release process is to decide on who is going to be the release manager, i.e. who is going to ensure that all the steps are taken to ensure a good release. This will typical involve someone volunteering and a vote on the dev list. The next thing is the create a branch where the code can be stabilized and testing can start on the release artifacts. It's useful to try and ensure that the code is complete as possible and that all the samples run before the branch is created. This removes the need for a lot of double fixing between the branch and the trunk. The commands in this document make use of the following environment variables, and are written in a form suitable for execution in linux or a cygwin shell on windows. If you set up these variables you should be able to just cut and paste the commands as given throughout this document. export PAOUSER=kelvingoodson export RELEASE=2.0-M5 export CURRENT_TRUNK_LEVEL=2.0-SNAPSHOT export NEXT_TRUNK_LEVEL=2.0-SNAPSHOT export RC=RC3 export RATJAR=~/apache-rat-0.7-SNAPSHOT.jar export SCPCOMMAND=scp Create the branchsvn copy https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/ https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/branches/sca-java-$RELEASE -m "Branch for $RELEASE" Once the branch is created, if the current and next trunk version differ, the version number in trunk can be updated. If the release is a milestone release the trunk version will not change. Fix up the branch workFirst checkout the branch so that you can work on it. These commands assume that a local directory called "branches" is present. cd branches svn co https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/branches/sca-java-$RELEASE ./$RELEASE Remove all the files that are not going to be part of the release, test all the samples and check all of the LICENSE and NOTICE files. Check dependencies are as you would expect them to be. In particular check that we aren't depending on many different versions of third part jars. If we are this has the side effect of messing up the generated build files. If module A depends on x.jar v1.2 and module B depends on x.jar v1.3 then when a build file that is generated for a sample that only depends on module A the stated x.jar dependency will be v1.2. Of course the distribution build will make sure that only v1.3 is actually shipped and so the ant build will fail. (TODO - need better automation) cd sca mvn \-o \-Pdependencies \-Dmaven.test.skip=true find . \-name dependency.txt \-exec cat '{}' >> deptotal.txt \; or cd sca mvn dependency:tree Use you favorite spreadsheet tool to open deptotal.txt and order on the first column to see across the project what dependencies we have on what libraries/versions. Once the branch is at the stage where a release candidate can be created for testing prepare to make a tag. "Tip" When making changes to a branch or tag that are also relevant to the trunk, it's much easier to apply the changes to the trunk at the time, rather than wait and risk losing the changes. Svn provides a simple one line way to do this with the "svn merge" command. In the root directory of a checked out version of the trunk, if you run a command like the following ... svn merge \-r 674473:674474 https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/branches/sca-java-2.0-M5 2.0-M5-RC2 Note how the version numbers in the n:m differ by one, so that you get just the difference in repository state from immediately before the change in question, to the state in question, merged into the file system in the target location (final argument) then that will apply the same edits as were made in the 674474 commit in the tag; merging them into your checked out version of the current trunk. The earlier you do this, the less likely that svn will present you with conflicts to resolve. Create Tag $RELEASE-$RCThese commands assume that a local directory called "tags" is present. cd tags svn co https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/branches/sca-java-$RELEASE $RELEASE-$RC Notice that all we are doing here is just checking out the branch again. This allows any last minute fixes to be taken from the branch in subversion and allows the version numbers in the tag to be corrected without affecting the branch, assuming that more than one tag will be required to complete the release process. Fix the release datesIn various files under distribution/src/main/release the month of release is quoted. Fix this to be the expected release month. Check the notice datesIt's not clear what the policy for dates in notice files is currently. We have gone for the following... Copyright (c) 2005 - 2009 The Apache Software Foundation As the project moves forward we need to check that the last date matches the current year. If you need to change all the notice files here's a script for i in `/usr/bin/find . \-name "NOTICE"`; do sed "s/Copyright (c) 2005 - 2008/Copyright (c) 2005 - 2009/g" $i >/tmp/tmp.notice; cp /tmp/tmp.notice $i; done Change the version IDThe "-SNAPSHOT" is removed from the end of the version string. This ensures that the only thing building with the release version number on your PC is the tag being tested. cd tags/2.0-M5-RC2 for i in `/usr/bin/find . \-name "*.xml" \-o \-name "*.java"`; do if grep $RELEASE-SNAPSHOT $i>/dev/null; then sed "s/$RELEASE-SNAPSHOT/$RELEASE/g" $i >/tmp/tmp.txt; cp /tmp/tmp.txt $i; echo $i; fi; done Generate the RAT reportCreate the report. cd tags java \-jar c:\Dev\downloads\apache-rat-0.7-SNAPSHOT.jar $RELEASE-$RC > rat-$RELEASE-$RC.txt Copy the report up onto the staging repo. You should of course check the report at this stage. E.g. with pageant running and your ssh key for people.apache.org registered with pageant $SCPCOMMAND rat-$RELEASE-$RC.txt $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/ "Tip" If you need to regenerate the RAT report after you have started on the steps that follow run "mvn clean" first to avoid complains about the files under target folders Build from top levelcd tags/$RELEASE-$RC mvn -o clean install Build distributioncd tags/$RELEASE-$RC/distribution/all mvn -Pdistribution Copy the distribution to somewhere and try itcd tags/$RELEASE-$RC/distribution/all/target cp apache-tuscany-sca-all-$RELEASE.zip <someplace> cp apache-tuscany-sca-all-$RELEASE-src.zip <someotherplace> Try all the samples/demos The war samples are currently to be tested with
Clean you local repo of SCA modules and compile the source distro and run some samples. As you will have deleted the maven-tuscany-plugin artifact, you'll need to do a 3 part manual maven build, building in the modules directory, then the maven directory, and finally the samples directory. Check for copyrights in the code to ensure that are what you are expecting grep \-iR \--exclude=LICENSE \--exclude=NOTICE Copyright * \| awk '{if (\!match($0, ".+ASF.+")) {print $0}}' check all the NOTICE files for i in `find . \-name NOTICE`; do echo XXXXXXXXXXXXXXXXXXXXXXXXXXXX; echo $i; cat $i; done > ../tmp Check for any SNAPSHOTS left in by mistake grep \-r \--include=*.xml SNAPSHOT * Check the LICENSE file against what is provided in the distributions. There is no automation for this bit. Check that all jars in the distribution\lib is mentioned on the binary LICENSE for fn in `find . -name "*.jar" \-printf "%f\n"`; do if grep \-q $fn ../LICENSE; then "-"; else "$fn NOT present"; fi; done; And check that all jars that are mentioned are present for fn in `awk '/.jar/ {if (match($0,"[a-zA-Z0-9._\-|a-zA-Z0-9._-]+[.]jar")) {print substr($0, RSTART,RLENGTH) } }' ../LICENSE`; do if ls * \| grep -q $fn; then echo "-";else echo ">>> $fn NOT present"; fi; done Check for junk included by accident find . \-name log \-print find . \-name work \-print find . \-name lck \-print find . \-name activemq-data \-print find . \-name temp \-print find . \-name tmp \-print Once you are happy with the release artifacts you can sign them and make them available from review. Sign the artifactsLinux cd tags/$RELEASE-$RC/distribution/target for i in \*.zip \*.gz; do gpg \--output $i.asc \--detach-sig \--armor $i; done for i in *.zip \*.gz; do openssl md5 \-hex $i \| sed 's/MD5((**[\^)|]*))= ([0-9a-f|0-9a-f]\*)/\2 \*\1/' > $i.md5; done Windows: for %A in (*.zip) do gpg \--output %A.asc \--detach-sig \--armor %A for %A in (*.gz) do gpg \--output %A.asc \--detach-sig \--armor %A for %A in (*.zip) do gpg \--print-md md5 %A > %A.md5 for %A in (*.gz) do gpg \--print-md md5 %A > %A.md5 The commands above should produce artifacts of an appropriate format, as follows. md5 should look like 8fb7cb398063ed0dffa414168468fffc \*apache-tuscany-sca-1.1-incubating.zip asc should look like \---\--BEGIN PGP SIGNATURE-\---\- Version: GnuPG v1.4.5 (Cygwin) iD8DBQBHnLGGE8fTrnkHPxIRAqPmAJ4tOR6W663FKCXHPi1GlLBWDyZwJgCeMqbb 68DOq0YsU/O7kJsBHuZXhJw= =elh0 \---\--END PGP SIGNATURE-\---\- Put the artifacts up in your home directory on people.apache.orgcd tags/$RELEASE-$RC/distribution/target pscp \*.asc $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/ pscp \*.md5 $PAOUSER@people.apache.org:public_html/sca-java/2.0-M5/RC2/ pscp \*.zip $PAOUSER@people.apache.org:public_html/sca-java/2.0-M5/RC2/ pscp \*.gz $PAOUSER@people.apache.org:public_html/sca-java/2.0-M5/RC2/ cd tags/1.1-RC3a/distribution/src/main/release pscp RELEASE_NOTES $PAOUSER@people.apache.org:public_html/sca-java/2.0-M5/RC2/ pscp CHANGES $PAOUSER@people.apache.org:public_html/sca-java/2.0-M5/RC2/ Check permissions on the fileschmod 644 \*.zip chmod 644 \*.gz chmod 644 \*.txt Deploy the maven artifactsNote below that the reference to "me.people" in the "id" part of the -DaltDeploymentRepository argument to the maven deploy plugin is simply an identifier relating to a stanza in your local maven repo's settings.xml file. Note that also if you use ssh authentication by referencing a file containing your private key from the settings.xml file, then be sure to use a file in open ssh format. People who have followed the apache instructions for creating ssh keys on Windows with putty will probably not have created open ssh format files. You can however convert your .ppk file to the open ssh forrmat by loading it into puttygen and using the conversion menu. Create a maven directory in your target directory on people.apache.org cd tags/2.0-M5-RC2 mvn \-N \-DaltDeploymentRepository=e.people::default::scp://people.apache.org/home/kelvingoodson/sca-java/2.0-M5/RC2/maven verify gpg:sign install:install deploy:deploy \-Dgpg.passphrase= cd shades/base mvn clean mvn \-DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/kelvingoodson/sca-java/2.0-M5/RC2/maven verify gpg:sign install:install deploy:deploy \-Dgpg.passphrase= cd modules mvn clean mvn \-DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/kelvingoodson/sca-java/2.0-M5/RC2/maven verify gpg:sign install:install deploy:deploy \-Dgpg.passphrase= cd maven/maven-tuscany-plugin mvn clean mvn \-DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/kelvingoodson/sca-java/2.0-M5/RC2/maven verify gpg:sign install:install deploy:deploy \-Dgpg.passphrase= cd features mvn clean mvn \-DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/kelvingoodson/sca-java/2.0-M5/RC2/maven verify gpg:sign install:install deploy:deploy \-Dgpg.passphrase= Check that the Maven artifacts workPoint you maven build at your p.a.o dir as a temporary mirror, for example, add mirror element to the settings.xml file (usually found at .m2/settings) <mirrors> <mirror> <id>ant.staging</id> <url>[http://people.apache.org/~kelvingoodson/sca-java/2.0-M5/RC2/maven]</url> <mirrorOf>???? what should this be - not apache.incubator as I found it (KG)</mirrorOf> </mirror> </mirrors> Clean you local SCA artifacts and use maven to compile samples and see if they run. Check in the tagsvn copy 2.0-M5-RC2 https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-M5-RC2 -m "Tag for 2.0 M5 RC2" Start votingThe PPMC will vote first. This may give rise to a new release candidate being required. If so you need to go back and start at the "Create Tag" step but using the next RC number. Once the PPMC vote is complete the vote is moved across to the IPMC. Once all the votes are complete the artifacts that have been voted on can be release. Once all the voting is complete(more yet to be ported from 1.x doc) |