-
Notifications
You must be signed in to change notification settings - Fork 2
Release management
Release management is about managing the process of building, packaging and distributing software for consumption. In open source software projects it is important that the software is released early and often. It is essential to have a well-defined process in place for creating these releases - much more important, in fact, that it is for most other activities in software development. This is necessary to ensure that all legal issue are addressed and that the quality of a release is good enough to be useful to users. This does not mean that a release must be complete or that it must be bug-free; in practice, this is never really the case. It simply means that the status of each release is well documented, in order to manage user expectations. The tools that are important in an open source software project play an indispensable role in release management. The most important tools in this respect are:
- Mailing list for communication
- Issue tracker for release-planning and scope management
- Version control system for tracking and tracking a released code.
There are a number of roles in the release management process. The different roles in the release management process are:
- Architect: the person responsible for identifying, creating and implementing the release process
- Manager: the person overseeing the release process
- Facilitator: the liaison between all stakeholders in a release
The most important steps in the release management process include:
##Scope and Planning
There are a couple of issues that are generally important for open source projects, but become crucial when the project considers creating a release. First of all it is essential to ensure license compatibility of the code. It is likely that the project’s code depends on some external libraries, each of which will have it own software license. The architect will have to check whether the license of that library permits the project to redistribute it with its own code. This usually happen the first moment the library is used in the project, but in any case should be no later that when the first release is prepared. Also it is important for the project to make sure that all issues regarding intellectual property (IP) have been taken care of.
When preparing a new release, the release manager needs to determine its scope and planning. They should involve the committers and users and seek some level of agreement from them about the scope and planning of the release. This is because the users will play a very important role in testing the prospective release and adopting the release once it has been made final. For this reason all communication about the scope and planning of the release should be publicly accessible, for example via a public mailing list. While this process is usually overseen by the release manager, it may be controlled by the facilitator.
Central to the release-planning process is the issue tracker. This tool is used to document the status of all issues relating to the project and provides a means of scheduling and keeping track of which issues will be in which release. From a technical perspective, it will usually be the architect who will need to analyse the list of unresolved issue prior to release. In collaboration with the release manager, they will decide which issues will be resolved in this release and which will be moved to a later release. If the issue had previously been scheduled for a release but after consideration is being delayed, this should be recorded in the release documentation so that users will know that this part of the schedule has not been met.
##Version Numbering
Each release will have to be uniquely identifiable by a version number. These numbers are not fully arbitrarily but are used according to a specific scheme that will give you additional information about the release. There are various schemes for expressing version numbers in software releases.
The more common scheme is whereby version numbers are of the form x.y.z or major.minor.micro. The major number is increased only when a significant amount of new functionality is added to the previous release. In such cases, the new release version number will be (x+1).0.0. The minor version number is increased only when some functionality is added to the new release, in which case the new release version number will be x.(y+1).0. When the new release consists mainly of bug fixes, there will be a so-called point release or QFE (quick fix engineering). The version number of the new release in such cases will only have the micro version number increased, resulting in x.y.(z+1). It is also possible to use postfixes in the version number to indicate the stability of the code. For example, -alpha indicates unstable code, while -beta indicates code with a stable API but that may still have bugs in it.
##Release Candidates
It is a good practices to create a release candidate (RC) before publishing a final release. An RC is a normal release, except that the version number has a postfix of -RCx (x starting at 1 and increasing with every new release candidate) to indicate that it is not the final release. This means that it has not yet been approved and may contain critical bugs. The release candidate will be created using the version control system. It allows the project to develop further on the main/master branch or trunk of the project, while work continues on the release in a separate release branch without interfering with the main development activities. It is useful to adopt a reasonable naming convention when creating a release branch or a tag. This allows tags to be recognized easily. Typically, the tag will be a variation on the name of the release. For example to use ALL CAPS to indicate release tags. Thus, foo-1.2 would be tagged FOO-1-2. It is generally better to use ‘-’ rather than ‘_’ as in most browsers ‘_’ gets lost when a hyperlink is underlined.
After the branch has been created the architect will assemble the binaries. This should be automated as much as possible to avoid duplication of effort and to ease that process of creating a release. Usually several distribution packages will be assembled at this stage for the different platforms the project supports.
##Publish and test the Release Candidate
The next phase of the release process is to make the release candidate available for testing. The packages can be distributed through the website, but it must be clear to users that it is not yet a final release. If the project is developing a web application, there may be a demo server available. This will be easier for less technical users to help test the release candidate. The availability of the release candidate should be announced widely on the publication channels to make sure that it gets tested by as many people and on as many different platforms as possible.
##Towards the Final Release
Critical bugs or errors found in the release candidate will have to be fixed before the final release is created. This will involve applying a patch to the release branch and creating a new release candidate with a different version number (postfix -RC2). This process should be repeated until no more critical errors are found. Once a release candidate has been fully tested, it needs approval to form the basis of the final release. The PMC will be the ultimate body to approve the release candidate. Once a release candidate has been approved, the architect will have to create the final release. It is a good practices to cryptographically sign the final release so that its integrity can be checked by anyone who downloads it. The release then must be available via the project’s distribution channels and the prospective users must be made aware of the new release via news announcements. The facilitator is responsible for this.
Other pages