<?xml version="1.0" encoding="ISO-8859-1" ?>
<!--
  ~  Licensed to the Apache Software Foundation (ASF) under one
  ~  or more contributor license agreements.  See the NOTICE file
  ~  distributed with this work for additional information
  ~  regarding copyright ownership.  The ASF licenses this file
  ~  to you under the Apache License, Version 2.0 (the
  ~  "License"); you may not use this file except in compliance
  ~  with the License.  You may obtain a copy of the License at
  ~
  ~   http://www.apache.org/licenses/LICENSE-2.0
  ~
  ~  Unless required by applicable law or agreed to in writing,
  ~  software distributed under the License is distributed on an
  ~   * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  ~  KIND, either express or implied.  See the License for the
  ~  specific language governing permissions and limitations
  ~  under the License.
  -->

<document>
    <properties>
        <title>Apache Synapse - Release Process</title>
    </properties>
    <body>
        <section name="Release Process">
            <p>
                We follow the standard <a href="http://www.apache.org/dev/release-publishing.html">ASF release process</a>.
                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 under
                <a href="https://svn.apache.org/repos/asf/synapse/branches">https://svn.apache.org/repos/asf/synapse/branches</a>.
                .
            </p>
            <p>
                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.
            </p>
            <p>
                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.
            </p>
            <p>
                All the release artifacts must be compliant with
                <a href="https://docs.sonatype.org/display/Repository/Central+Sync+Requirements">Maven central repository
                    requirements</a> . 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.
                <a href="http://www.apache.org/dev/publishing-maven-artifacts.html">http://www.apache.org/dev/publishing-maven-artifacts.html</a>
            </p>
            <p> The details on Nexus Repository Management can be found in <a href="http://www.sonatype.com/books/nexus-book/reference/staging.html">Repository Management with Nexus</a>.

            </p>
        </section>

        <section name="Trouble Shooting and Best Practices">
            <ul>
                <li>
                    <ul>
                        <li>Cannot Close the Staging Repo : Make sure RM's public keys are upload to apache key servers</li>
                    </ul>
                    <ul>
                        <li>Avoid .bck poms in source distribution.</li>
                    </ul>
                    <ul>
                        <li>Always run a mvn release:prepare -DdryRun=true before the actual preparation</li>
                    </ul>
                    <ul>
                        <li>Test the generated site with <a href="http://validator.w3.org/checklink">w3c validator</a>.</li>
                    </ul>

                </li>
            </ul>

        </section>
    </body>
</document>