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