Releasing a Git Repository

If a Git repository is already set up as explained in setting up a git repository, the following steps can be followed to release the repository.

Create a git release branch from the master. The branch name would be "release-<release-version>".
```
git checkout -b release-<release-version> master
```
Maven release plugin does not update some properties that we use, such as the osgi import and export versions. These properties also have the “SNAPSHOT” part in it. This has to be manually updated before performing the release preparation command.

Also make sure that the project does not have any SNAPSHOT dependencies and update those with released versions. If there are any unreleased SNAPSHOT dependencies, we will have to release them separately. This will anyway be checked by the release plugin during the release:prepare stage.
To test the above, we can use the “dryRun” option with the maven release plugin.
Issue the following release preparation command: mvn release:clean release:prepare.
The build artifacts will have this username in its MANIFEST file. Give appropriate values for the release, development, and tag versions as shown below when prompted for the release preparation command. Use the git tag versioning strategy “v1.x” when the tag version prompted : http://git-scm.com/book/en/v2/Git-Basics-Tagging.

[INFO] Checking dependencies and plugins for snapshots …
What is the release version for "WSO2 Carbon Kernel"? (org.wso2.carbon:carbon-kernel) 4.3.0: : 4.3.0
What is SCM release tag or label for "WSO2 Carbon Kernel"? (org.wso2.carbon:carbon-kernel) carbon-4.3.0: : 4.3.0
What is the new development version for "WSO2 Carbon Kernel"? (org.wso2.carbon:carbon-kernel) 4.3.1-SNAPSHOT: : 4.4.0-SNAPSHOT
Once you have completed the above steps, it is recommended to perform some checks as shown below.
Recommended Checks:

1. Copy all the generated jars and zips to one place and extract them all.
mkdir /tmp/artifacts1/
cp `find . -iname *jar` /tmp/artifacts1/
cp `find . -iname *zip` /tmp/artifacts1/
cd /tmp/artifacts1/; for x in `ls`; do echo $x; unzip $x -d $x.unzip; done
2. Do a grep. Ideally, this should not return anything.
grep -ri "\${" . --include=MANIFEST.MF --include=feature.xml
grep -ri “version=\"0\.0\.0\.” . --include=feature.xml ##yet to test this command
grep -ri "Build-Jdk" . --include=MANIFEST.MF --include=feature.xml ##Should be 1.6.x
3. Open the root pom from the release tag and make sure there are no snapshot dependencies or properties.
4. Sources should be built using JDK 1.6.x.
5. Optional - Use the builder machine to perform the release. Please request for credentials.
6. If the above looks fine, then you can proceed to release:perform. After doing release:perform, go to target/checkout/ folder at the repo root folder.
7. Repeat step 1. This time, copy it to a different folder.
8. Do a grep : grep -ri "SNAPSHOT" . --include=MANIFEST.MF --include=feature.xml
This too shouldn't return anything.
Issue the release perform command: mvn release:perform.
When the above process succeeds, the artifacts will be deployed to a staging repo. The newly created staging repo will not be closed automatically when the artifacts are uploaded. This can be done through the release-manager. That is, by logging into the nexus UI the repo can be manually closed. When a staging repo is closed, it becomes available for public access. Eg: http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-037/
If there is a failure, the prepared release process can be rolled back using the following command: mvn release:rollback.
This will revert all the commits made during the preparation process.

When we are starting over again, always use a clean maven repo.
With the staging repo in effect, a release candidate VOTE should be called on dev@wso2.org using the template given below. This VOTE is essential for a product release. For other projects, this is optional.

Subject : [VOTE] Release <Project Name> <Project Version> <RC #>
<BEGIN>
This is the <RC #> release candidate of <Project Name> <Project Version>
Eg : WSO2 Carbon Kernel 4.3.0 rc1
This release fixes the following issues:
<URL to the fixed jira list>
Please download, test and vote. Please refer the release verification guide for detailed information on verifying this release.

Source & binary distribution files:
<URL to the source and binary files>

Maven staging repo:
<URL to the maven nexus staging repo>
Eg: http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-1000/

The tag to be voted upon:
<URL to the release tag location>
Eg: https://github.com/wso2/carbon4-kernel/releases/tag/carbon4-kernel-4.3.0-rc1

KEYS file containing PGP keys we use to sign the release:
<URL to the Keys used with signing the artifacts>

Release verification guide:
<If any>

[ ] Broken - do not release (explain why)
[ ] Stable - go ahead and release
</BEGIN>
A release VOTE should be kept open for 72 hours. During this period, the developers should test the artifacts and then vote. When there are at least 3 binding +1 votes and no -1 votes, the vote is considered as a pass. Once the release vote is completed (the artifacts are tested and verified), the staging repo can be released, which will make the artifacts available in the public maven repo. Note that this should be done by the release manager. The released artifacts will be available in the WSO2 Releases maven repository at : http://maven.wso2.org/nexus/content/repositories/releases/
If the vote failed, then the staging repository should be dropped and the changes for the release branch should be reverted. This process should be started again from #1 onwards, after fixing the issues mentioned during the vote.

Always use clean maven repo when you start over.
Finally, when you are done with the release, merge the release branch with the master. You can create a pull request for this from release-<release-version> to master.