<!--
  ~ 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.
  -->

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content=
"HTML Tidy for Windows (vers 14 June 2007), see www.w3.org" />
<meta http-equiv="content-type" content="" />
<title>Axis2 Release Process</title>
<link href="css/axis-docs.css" rel="stylesheet" type="text/css"
media="all" />
</head>
<body>
<h1>Release Process</h1>
<h3>Cutting a branch</h3>
<ul>
<li>When a release is ready to go, release manager (RM) puts
forward a release plan as per standard Apache process, including
dates. This gets VOTEd on by the committers. During this period the
trunk is still the only relevant source base.</li>
<li>As soon as a release is approved (or even before), RM should
add the new version into JIRA as a target.</li>
<li>At the point where we would normally do the "code freeze" for a
release, the RM cuts a branch named for the release. This branch is
where the release candidates and releases will happen.</li>
<li>Ideally a release branch is only around for a week or maybe two
before the release happens.</li>
<li>The only things that should EVER get checked into the release
branch are - 1) bug fixes targeted at the release, 2)
release-specific updates (documentation, SNAPSHOT removal, etc). In
particular new functionality does not go here unless it is a
solution to a JIRA report targeted at the release.</li>
<li>Normal development continues on the trunk.</li>
</ul>
<h3>Dependencies and branches</h3>
<ul>
<li>The trunk should always be "cutting edge" and as such should
usually be pointing at SNAPSHOT versions of all dependencies. This
allows for continuous integration with our partner projects.</li>
<li>Soon after a release branch is cut, the RM is responsible for
removing ALL dependencies on SNAPSHOT versions and replacing them
with officially released versions. This change happens only on the
release branch.</li>
</ul>
<h3>Managing change and issue resolution with a release branch</h3>
<ul>
<li>The RM goes through JIRA issues and sets "fix for" to point to
both "NIGHTLY" and the new branched release number for the fixes
that are targeted for the release after the branch is cut.</li>
<li>In general, the assignee/coder fixes JIRA issues or makes other
changes *on the trunk*. If the JIRA issue is targeted at the
release, or upon coder's discretion, they then merge the fix over
to the release branch.</li>
<li>This way the trunk is ALWAYS up-to-date, and we don't have to
worry about losing fixes that have only been made on the release
branch.</li>
<li>When the assignee resolves an issue, they confirm it's been
fixed in both branches, if appropriate.</li>
</ul>
<h3>Checking changes into the branch</h3>
<ul>
<li>If bug fixes are needed later for a release which has long
since happened (to fix user issues, etc), those fixes generally
should also happen on the trunk first assuming the problem still
exists on the trunk.</li>
<li>There are only two cases where we would ever check anything
into the branch without first checking it into the trunk. 1)
Release specific items (release number references, release notes,
removal of SNAPSHOTs), and 2) if the trunk has moved on in some
incompatible way.</li>
</ul>
</body>
</html>