Page History

Section

border	false

Column

width	15%

Include Page

	Menus
	Menus

Column

width	85%

Getting Ready

Setting up ssh

Create signing key

Get hold of RAT

Useful Resources

Incubator release best practice
Incubator Policy
ASF Developer Guide
ASF Release FAQ
ASF Release Licensing FAQ
ASF Release Signing
ASF Comitters Guide
Henk's ASF Key Guide
Surfnet Key Server
MIT Key Server
Raymond's release script

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

Release Manager Release Process

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

Code Block


export RELEASE=2.0-M5
export RC=RC3

export CURRENT_TRUNK_LEVEL=2.0-SNAPSHOT
export NEXT_TRUNK_LEVEL=2.0-SNAPSHOT

export RATJAR=~/apache-rat-0.7-SNAPSHOT.jar
export SCPCOMMAND=scp
export PAOUSER=kelvingoodson
export PASSPHRASE=your_pao_authentication_pass_phrase

Create the branch

Code Block
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-$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 work

First checkout the branch so that you can work on it. These commands assume that a local directory called "branches" is present.

Code Block
cd branches svn co

Wiki Markup

{section:border=false} {column:width=15%} {include: Menus} {column} {column:width=85%} 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 jar (/) 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 {code} 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>" {code} Once the branch is created the version number in trunk can be updated. 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. {code} cd branches svn co [

https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/branches/sca-java-

2.0-M5]

$RELEASE ./

2.0-M5 {code} 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) {code} {code} cd sca mvn -o -Pdependencies

$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)

Code Block
cd sca mvn \-o \-Pdependencies \-Dmaven.test.skip=true find . \-name dependency.txt \-exec cat '{}' >> deptotal.txt \;

{code} or {code}

or

Code Block
cd sca mvn dependency:tree

{code}

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.

{

Note

:

title

=

	"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

Create Tag $RELEASE-$RC

These commands assume that a local directory called "tags" is present.

Code Block
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 {code} 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

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

following...

Copyright

(c)

2005

-

2009

2010 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

{

Code Block

}


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

{code} h4. Change the version ID The

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.

{

Code Block

}


cd tags/2.0-M5-RC2 for i in `/usr/bin/find . \-name ".xml" \-o \-name ".java"`; do if grep

2.0-M5-SNAPSHOT

$RELEASE-SNAPSHOT $i>/dev/null; then sed "s/

2.0

$RELEASE-

M5-

SNAPSHOT/

2.0

$RELEASE/g" $i >/tmp/tmp.txt; cp /tmp/tmp.txt $i; echo $i; fi; done

{code} h4. Generate the RAT report Create the report. {code} cd tags java -jar c:\Dev\downloads\apache-rat-0.7-SNAPSHOT.jar 2.0-M5-RC2 > rat-2.0-M5.txt {code} 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 {code} pscp rat-2.0-M5.txt kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/ {code} {note:title="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 {note} h4. Build from top level {code} cd tags/2.0-M5-RC2 mvn -o clean install {code} h4. Build distribution {code} cd tags/2.0-M5-RC2/distribution/all mvn -Pdistribution {code} h4. Copy the distribution to somewhere and try it {code} cd tags/2.0-M5-RC2/distribution/all/target cp apache-tuscany-sca-all-2.0.zip <someplace> cp apache-tuscany-sca-all-2.0-src.zip <someotherplace> {code} Try all the samples/demos The war samples are currently to be tested with - Tomcat 5.5.20 and Tomcat 6.0.14 - Jetty 6.1.3 - Geronimo 2.0.2 Tomcat6 jee5 - WebSphere 6.1 fix pack 9\+ 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 {code} grep -iR --exclude=LICENSE --exclude=NOTICE Copyright * | awk '{if (!match($0, ".+ASF.+")) {print $0}}' {code} check all the NOTICE files {code} for i in `find . -name NOTICE`; do echo XXXXXXXXXXXXXXXXXXXXXXXXXXXX; echo $i; cat $i; done > ../tmp {code} Check for any SNAPSHOTS left in by mistake {code} grep -r --include=*.xml SNAPSHOT * {code} 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 {code} for fn in `find . -name "*.jar" -printf "%f\n"`; do if grep -q $fn ../LICENSE; then "-"; else "$fn NOT present"; fi; done; {code} And check that all jars that are mentioned are present {code} for fn in `awk '/.jar/ {if (match($0,"[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 {code} Check for junk included by accident {code} 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 {code} Once you are happy with the release artifacts you can sign them and make them available from review. h4. Sign the artifacts Linux {code} cd tags/1.1-RC3a/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]*$/\2 *\1/' > $i.md5; done {code} Windows: {code} 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 {code} The commands above should produce artifacts of an appropriate format, as follows. md5 should look like {code} 8fb7cb398063ed0dffa414168468fffc *apache-tuscany-sca-1.1-incubating.zip {code} asc should look like {code} -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQBHnLGGE8fTrnkHPxIRAqPmAJ4tOR6W663FKCXHPi1GlLBWDyZwJgCeMqbb 68DOq0YsU/O7kJsBHuZXhJw= =elh0 -----END PGP SIGNATURE----- {code} h4. Put the artifacts up in your home directory on people.apache.org {code} cd tags/1.1-RC3a/distribution/target pscp *.asc kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/ pscp *.md5 kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/ pscp *.zip kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/ pscp *.gz kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/ {code} {code} cd tags/1.1-RC3a/distribution/src/main/release pscp RELEASE_NOTES kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/ pscp CHANGES kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/ {code} h4. Check permissions on the files {code} chmod 644 *.zip chmod 644 *.gz chmod 644 *.txt {code} h4. Deploy the maven artifacts Note 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|http://www.apache.org/dev/user-ssh-windows.html] 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. {code} Create a maven directory in your target directory on people.apache.org {code} 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 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=

Build from top level

Code Block
cd tags/$RELEASE-$RC mvn -o clean install

Build distribution

Code Block
cd tags/$RELEASE-$RC/distribution/all mvn -Psource mvn

Copy the distribution to somewhere and try it

Code Block
cd 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

Tomcat 5.5.20 and Tomcat 6.0.14
Jetty 6.1.3
Geronimo 2.0.2 Tomcat6 jee5
WebSphere 6.1 fix pack 9+

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

Code Block
grep \-iR \--exclude=LICENSE \--exclude=NOTICE Copyright * \\| awk '{if (\!match($0, ".+ASF.+")) {print $0}}'

check all the NOTICE files

Code Block
for i in `find . \-name NOTICE`; do echo XXXXXXXXXXXXXXXXXXXXXXXXXXXX; echo $i; cat $i; done > ../tmp

Check for any SNAPSHOTS left in by mistake

Code Block
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

Code Block
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

Code Block


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

Code Block
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

Generate the RAT reports

Unpack a binary and source distribution archive and create rat reports for each.

Code Block
java \-jar $RATJAR srcExtractionDir > rat-$RELEASE-$RC-src.txt java \-jar $RATJAR binExtractionDir > rat-$RELEASE-$RC-bin.txt

Copy the reports up onto the staging repo. You should of course check the report at this stage.

Code Block
$SCPCOMMAND rat-$RELEASE-$RC.txt $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/

Note

title	"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

Once you are happy with the release artifacts you can sign them and make them available from review.

Sign the artifacts

Linux

Code Block


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:

Code Block


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

Code Block
8fb7cb398063ed0dffa414168468fffc \*apache-tuscany-sca-1.1-incubating.zip

asc should look like

Code Block
\---\--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.org

Code Block


cd tags/$RELEASE-$RC/distribution/target
$SCPCOMMAND *.asc $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/
$SCPCOMMAND *.md5 $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/
$SCPCOMMAND *.zip $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/
$SCPCOMMAND *.gz $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/

Code Block


cd tags/$RELEASE-$RC/distribution/src/main/release
pscp RELEASE_NOTES $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/
pscp CHANGES $PAOUSER@people.apache.org:public_html/sca-java/$RELEASE/$RC/

Check permissions on the files

Code Block
chmod 644 \.zip chmod 644 \.gz chmod 644 \*.txt

Deploy the maven artifacts locally

As a potentially simpler alternative to deploying directly to p.a.o you can do the following (I have to use this approach as I
can't get mvn to authenticate with p.a.o properly during deployment)

Build the maven release artifact to a local directory (in this case target/deploy at the top level):

Code Block
cd tags/$RELEASE-$RC mvn -Prelease -DaltDeploymentRepository=id::default::file:target/deploy

Copy the artifacts up to p.a.o:

Code Block
cd cd tags/$RELEASE-$RC/target/deploy scp -r org slaws@people.apache.org:./public_html/tuscany/2.0-beta1-RC2/maven

Deploy the maven artifacts directly to p.a.o

Note 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 format by loading it into puttygen and using the conversion menu.

Create a maven directory in your target directory on people.apache.org

Code Block


cd tags/$RELEASE-$RC
mvn -N -DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/$PAOUSER/public_html/sca-java/$RELEASE/$RC/maven verify gpg:sign install:install deploy:deploy -Dgpg.passphrase=$PASSPHRASE


cd modules

mvn clean
mvn \-DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/$PAOUSER/public_html/sca-java/$RELEASE/$RC/maven verify gpg:sign install:install deploy:deploy -Dgpg.passphrase=$PASSPHRASE

cd shades (note, I thought it was only shades/base that needed doing, but the maven plugin failed on shades artifacts, so I deployed from shades)
mvn clean
mvn \-DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/$PAOUSER/public_html/sca-java/$RELEASE/$RC/maven verify gpg:sign install:install deploy:deploy -Dgpg.passphrase=$PASSPHRASE


cd maven/maven-tuscany-plugin

mvn clean
mvn \-DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/$PAOUSER/public_html/sca-java/$RELEASE/$RC/maven verify gpg:sign install:install deploy:deploy -Dgpg.passphrase=$PASSPHRASE

cd features

mvn clean
mvn \-DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/$PAOUSER/sca-java/$RELEASE/$RC/maven verify gpg:sign install:install deploy:deploy -Dgpg.passphrase=$PASSPHRASE

Deploy source jars

Code Block
cd modules mvn -Psource -DaltDeploymentRepository=me.people::default::scp://people.apache.org/home/kelvingoodson/public_html/sca-java/2.0-M5/RC3/maven -Dgpg.passphrase=$PASSPHRASE deploy

Check permissions of maven artifacts

If you've copied the maven artifacts up to p.a.o manually you may need to fix the permissions of the directories

Code Block
find . -type d -exec chmod 755 {} \;

and files

Code Block
find . -type f -exec chmod 644 {} \;

Check that the Maven artifacts work

Point 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)

Code Block
<mirrors> <mirror> <id>ant.staging</id> <url>http://people.apache.org/~<PAOUSER>/sca-java/<release>/<RC>/maven</url> <mirrorOf>*</mirrorOf> </mirror> </mirrors>

Clean you local SCA artifacts and use maven to compile samples and see if they run.

Check in the tag

Code Block
cd tags svn copy $RELEASE-$RC https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/$RELEASE-$RC -m "Tag for $RELEASE $RC"

Start voting

The 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

Copy the artifacts from you directory on people.apache.org to;

Code Block
/www/www.apache.org/dist/tuscany/java/sca/$RELEASE

Also check that the KEYS file is up to date.

Code Block
/www/www.apache.org/dist/tuscany

Copy the staging repo to the live repo

Option 1 (untested for 2.0-M5)

Code Block
mvn stage:copy -Dsource="http://people.apache.org/~slaws/tuscany/1.1-RC3a/maven" -Dtarget="scp://<userid@>people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository" -Dversion=1.1

You'll need the maven stage plugin to do this. Since maven-stage-plugin is not published, the release manager should checkout the source for the plugin and build it.

Code Block
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-stage-plugin/

Or option 2 (used for 2.0-M5), instead of using the Maven stage plugin just manually copy the artifacts there:

Code Block


cd public_html/sca-java/$RELEASE/$RC/org/apache/tuscany/
cp -p -v -R  sca/  /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/tuscany/sca
cp -p -v -R  maven/  /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/tuscany/maven

Check the permissions in the repo

There is a script in the SNAPSHOT report that sets the permissions correctly; take a look at the contents of the script and adjust for your purposes

Code Block
more /www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh

For example:

Code Block


cd /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/tuscany/
find . ! -perm 775 -type d -user ${USER} -exec chmod 775 {} \; -print
find . ! -perm 664 -iname maven-metadata.xml* -user ${USER} -exec chmod 664 {} \; -print
find . -group slaws -exec chgrp committers {} \; -print

Copy the release candidate tag to the final tag name.

Code Block
svn copy https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/$RELEASE-$RC/ https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/$RELEASE -m "Copy $RC tag as final release tag"

Update the website

Edit the wiki that defines the website content https://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+2.x+Releases

Wait for the artifact and website changes to be updated

The website will be updated from the wiki within a few hours. Once updated, check that the new download pages work correctly. In particular follow the download links for artifacts right through to a selection of mirror download sites to be sure that the distributions have been mirrored.

Beat the Drum!

send an announcement, using your apache.org email address, to the apache announce list, and to the tuscany dev and user lists. Blog the announcement on the Tuscany blog and any other publicity that seems appropriate.

Versions Compared

Old Version 11

New Version Current

Key

Getting Ready

Useful Resources

Release Reviewer Check List

Release Manager Release Process

Call for releases

Create the branch

Fix up the branch work

Create Tag $RELEASE-$RC

Fix the release dates

Check

the

notice

dates

It's

Change the version ID

Build from top level

Build distribution

Copy the distribution to somewhere and try it

Generate the RAT reports

Sign the artifacts

Put the artifacts up in your home directory on people.apache.org

Check permissions on the files

Deploy the maven artifacts locally

Deploy the maven artifacts directly to p.a.o

Deploy source jars

Check permissions of maven artifacts

Check that the Maven artifacts work

Check in the tag

Start voting

Once all the voting is complete

Copy the staging repo to the live repo

Check the permissions in the repo

Copy the release candidate tag to the final tag name.

Update the website

Wait for the artifact and website changes to be updated

Beat the Drum!