tuscany-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Tuscany Docs 2.x > Making Releases
Date Thu, 03 Jun 2010 13:36:00 GMT
Space: Apache Tuscany Docs 2.x (http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x)
Page: Making Releases (http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Making+Releases)

Edited by kelvin goodson:
{include: Menus}

h3. Getting Ready

[Setting up ssh]

[Create signing key]

[Get hold of RAT]

h3. Useful Resources

[Incubator release best practice |http://incubator.apache.org/guides/releasemanagement.html#best-practice]
[Incubator Policy |http://incubator.apache.org/incubation/Incubation_Policy.html]
[ASF Developer Guide |http://www.apache.org/dev/]
[ASF Release FAQ |http://www.apache.org/dev/release.html]
[ASF Release Licensing FAQ |http://www.apache.org/dev/release.html#license]
[ASF Release Signing |http://www.apache.org/dev/release-signing.html]
[ASF Comitters Guide |http://www.apache.org/dev/new-committers-guide.html#pgp]
[Henk's ASF Key Guide |http://people.apache.org/~henkp/]
[Surfnet Key Server |http://pgp.surfnet.nl/]
[MIT Key Server |http://pgp.mit.edu/]
[Raymond's release script|http://svn.apache.org/repos/asf/tuscany/java/etc/release-sca.sh]

h3. Release Reviewer Check List

(/) Check that all RELEASE-NOTES and READMEs etc have the right release number and date
(/) Check that the RAT output doesn't report missing or non-ASF licenses other than for files
that can't have ASF licenses.
(/) Check that all files (that need it) have the ASF copyright and it's the right date
(/) Check that the LICENSE and NOTICE files appear at the top level of source distro
(/) Check that the LICENSE and NOTICE files appear at the top level of binary distro
(/) Check that the LICENSE and NOTICE files appear at the top level of all maven modules that
will be distributed (these are the tricky ones as they get copied when people add new modules)
(/) Check that LICENSE files have a copy of all third party licenses for the files in directories
below them (jar name and version to which license relates must be clearly marked. Use the
list from the distribution lib dir)
(/) Check that NOTICE files have a copy of all of the copyright statements for the files in
directories below them. You have to go through all dependency jars/files that have been copied
in and check
(/) Check that the signatures are in the right format
(/) Check that the signing key is in the KEYS file and in an external repo
(/) Check that there are no SNAPSHOT dependencies still in the distribution
(/) Check that there is no junk left in the distributions (.log, .tmp, .bak etc)
(/) Check that the distribution match the tag as far as possible. (Our NOTICE files have the
module name dropped in automatically so don't match and we don't ship svg files)
(/) Check that the manifests in the jars that we produce have enough information (name of
product and version. Scripts below should do this).
(/) Check that the project depends on the smallest number of versions of each third party
(/) Check that all samples compile and run from the command line and where appropriate operate
correctly in Tomcat/WebSphere/Jetty/Geronimo
(/) Check that all demos compile and run from the command line and where appropriate operate
correctly in Tomcat/WebSphere/Jetty/Geronimo
(/) Check to make sure Javadocs are generated for APIs and SPIs.

h3. Release Manager Release Process

This page borrows many of the commands from [Raymond's release script|http://svn.apache.org/repos/asf/tuscany/java/etc/release-sca.sh]
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.

h4. 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.

h4. Create the branch

svn 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-2.<x>-M<y>
 -m "Branch for 2.<x> Milestone <y>"

h4. Fix up the branch work

First 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-2.0-M5] ./2.0-M5
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 \;


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.

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
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.

h4. Create Tag 2.0-M5-RC2

These 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-2.0-M5 2.0-M5-RC2

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.

h4. Fix the release dates

In various files under distribution/src/main/release the month of release is quoted. Fix this
to be the expected release month.

h4. Check the notice dates

It's not clear what the policy for dates in notice files is currently. We have gone for the

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

h4. Change the version ID

The "-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 2.0-M5-SNAPSHOT $i>/dev/null;
then sed "s/2.0-M5-SNAPSHOT/2.0/g" $i >/tmp/tmp.txt; cp /tmp/tmp.txt $i; echo $i; fi; done

h4. Generate the RAT report

Create the report.

cd tags
java -jar c:\Dev\downloads\apache-rat-0.7-SNAPSHOT.jar 2.0-M5-RC2 > rat-2.0-M5.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

pscp rat-2.0-M5.txt kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/

Change your notification preferences: http://cwiki.apache.org/confluence/users/viewnotifications.action

View raw message