More details of release management steps
|Deletions are marked like this.||Additions are marked like this.|
|Line 66:||Line 66:|
|== Release Early, Release Often ==||== Release Early, Release Often ==|
Like all pages in this wiki you are welcome (and encouraged) to contribute to this page by filling in the many gaps, either by providing links to other resources or by providing discussion content.
Open Source Development
There is more to open source than a licence. It is also a development methodology. This page links to various resources about different aspects of open source development.
User documentation is aimed at those people wishing to either use the software in a production environment or wishing to quickly evaluate the software before using in a production environment or becoming a developer on the project.
The kinds of documentation we would expect to find in this section are:
- A description of the project
- A feature list showing
- Details of user support mechanisms
- How to report bugs
- How to make feature requests
- A change log that indicates the important changes between released versions of the software
- Install instructions, including a description of any pre-requisites
- Getting started instructions
- Detailed user documentation
Developer documentation is aimed at those people wishing to work with the source code of the project. They may be motivated by the need to work with the latest and greatest code, or they may be motivated by the need to add features or fix bugs. Developers are also users, so they will be interested in user docs as well as developer docs.
The kinds of documents we would expect to find in this section are:
- How to retrieve the source code
- Build instructions
- Testing procedures
- Details of developer support mechanisms
- Contributor instructions, i.e. how to create and submit a patch
- Release process (See "Release Management" below)
- Governance Model
- Coding standards
SoftwarePatch - Working with patches
ContributorLicenceAgreements - a contributor licence agreement helps ensure that all contributions to the project can legally be included
Release Early, Release Often
An important part of open source development is the creation of a release for users of the software. Whilst the source code is freely available and usually developed in an open manner, potential developers and users will usually want to be able to evaluate the code quickly and easily. Therefore, projects should frequently release their software in a form that is easily accessible.
"Release early, release often" is a well known mantra of open source development. There are many reasons why it is important to release early and release often. Some of the more important ones are:
- Early and frequent feedback from users
- easy access to the latest and greatest features
- Builds developer confidence
- Shows genuine project activity
- Manageable upgrade path for users
Release Early, Release Often is part of building a sustainable open source project, releases produce users, users sometimes become contributors, contributors make the project stronger. The downside of releasing early and often is that you need to manage your user expectations. Be clear about the true status of your release and make any known bugs clear in your documentation.
Release Management is the process of building, packaging, and deploying of software for consumption. It is a process that is controlled by a Release Manager. A Release Manager is:
- Architect – helps to identify, create, and implement the release process
- Manager - of the release process
- Facilitator – is the liaison between all stakeholders in a release
The stakeholders in a release include:
- Developers of the software
- Quality Assurance engineers
- Users of the released software
- Press and marketing contacts
Building a version of the software to be considered for release should be a fairly easy process since the software build ought to be an almost fully automated process. However, some aspects of the release build process will be difficult if not impossible to automate.
There are likely to be multiple release candidates packages, for different platforms.
Each release candidate is identified by a [wiki:ReleaseVersionNumber version number].
Before becoming an official release a build of the software will undergo a phase of prerelease testing. Often the package being tested will be indicated in the [wiki:ReleaseVersionNumber version number], for example, it may be designated as a release candidate with the letters RC1, for release candidate one.
Once a release candidate has been fully tested it will be approved for release. This approval process will be dependent on the governance model adopted by the project.
Signing of the release package. Users need to be assured of the integrity of the downloaded package. Therefore the release should be signed.
Once a release has been approved it must be made available to users via the projects distribution channels. These channels should be capable of handling the expected demand for the release.
Of course, making a release available is not enough. They must be made aware of the new release via news announcements.
Additional Resources on Release Management
[http://en.wikipedia.org/wiki/Release_Management_method Wikipedia on Release Management Method]
[http://www.ics.uci.edu/~wscacchi/Papers/Open-Source-Research/OSSE3-Erenkrantz.pdf Release Management Within Open Source Projects by Justin R. Erenkrantz]
[http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO by Eric Steven Raymond]