Release Process

We follow the standard ASF release process. One of the committers would volunteer to play the release manager role for a given release. A few days will be spent on stabilizing the Synapse development trunk, improving its documentation and test coverage. When the code base is in a satisfactory state a release branch would be created.

From this point onwards all committers will switch to the newly created development branch. It is highly recommended to ensure that all the changes done on the development branch are also checked into the main development branch. Open JIRA issues will be reviewed and rearranged accordingly. Many of the issues will get resolved during this process and the remaining few will be accordingly prioritized and scheduled for a future release. The unit tests and integration tests will be used extensively during this critical period to keep the development branch in its most stable form.

Finally the release manager would trigger the release build, sign the generated artifacts and host them on people.apache.org for review. A release vote will be called urging all those interested to review the packs and provide feedback. Upon receiving the necessary number of votes, a release tag will be created and the release artifacts will be uploaded to the appropriate servers for distribution.

All the release artifacts must be compliant with Maven central repository requirements . Form synapse 2.1 release onwards, we follow the standard maven artifact releasing process. Most part of the release process is automated and all the required steps are listed here. http://www.apache.org/dev/publishing-maven-artifacts.html

The details on Nexus Repository Management can be found in Repository Management with Nexus.

Trouble Shooting and Best Practices

    • Cannot Close the Staging Repo : Make sure RM's public keys are upload to apache key servers
    • Avoid .bck poms in source distribution.
    • Always run a mvn release:prepare -DdryRun=true before the actual preparation