<!-- | |
~ 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> |