THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Section | ||
|---|---|---|
| ||
| Column | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
| Column | ||
|---|---|---|
| ||
Getting Ready
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.
Create the branch
| Code Block |
|---|
| 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.
...
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 [https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/branches/sca-java-2.0-M5] ./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 Block |
|---|
better automation) {code} {code} cd sca mvn \-o \-Pdependencies \-Dmaven.test.skip=true find . \-name dependency.txt \-exec cat '{}' >> deptotal.txt \; |
or
| Code Block |
|---|
{code} or {code} 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 | ||||
|---|---|---|---|---|
| =
| |||
| }
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 ... {code}
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. {note} h4. Create Tag |
Create Tag 2.0-M5-RC2
...
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 |
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.
...
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
...
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 $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 |
Generate the RAT report
Create the report.
| Code Block |
|---|
{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 Block |
|---|
} pscp rat-2.0-M5.txt kelvingoodson@people.apache.org:public_html/sca-java/2.0-M5/RC2/ {code} {note:title= |
| Note | ||
|---|---|---|
| ||
| }
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 level
| Code Block |
|---|
folders {note} h4. Build from top level {code} cd tags/2.0-M5-RC2 mvn \-o clean install {code} h4 |
Build distribution
| Code Block |
|---|
. Build distribution {code} cd tags/2.0-M5-RC2/distribution/all mvn \-Pdistribution {code} h4. Copy the distribution to somewhere and try it {code} |
Copy the distribution to somewhere and try it
| Code Block |
|---|
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 Block |
|---|
} grep \-iR \--exclude=LICENSE \--exclude=NOTICE Copyright * \| awk '{if (\!match($0, ".+ASF.+")) {print $0}}' {code} |
check
...
all
...
the
...
NOTICE
...
files
| Code Block |
|---|
} 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 Block |
|---|
} 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 Block |
|---|
{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 Block |
|---|
} for fn in `awk '/.jar/ {if (match($0,"[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 {code} |
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 {code} |
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/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|0-9a-f]\*\)/\2 \*\1/' > $i.md5; done {code} |
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 {code} |
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 {code} |
asc
...
should
...
look
...
like
| Code Block |
|---|
} \---\--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 |
Put the artifacts up in your home directory on people.apache.org
| Code Block |
|---|
} 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 |
| Code Block |
|---|
} 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/ { |
Check permissions on the files
| Code Block |
|---|
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 |
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 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 Block |
|---|
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 Block |
|---|
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=
...