THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| 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-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
| Code Block |
|---|
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)
|
...
| 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 ...
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
...
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 |
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 |
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 |