123 lines
5.8 KiB
Plaintext
123 lines
5.8 KiB
Plaintext
/** @page releases Release Processes
|
|
|
|
This page provides an introduction to the OpenOCD Release Proceses:
|
|
- @ref releaseswhy
|
|
- @ref releaseswho
|
|
- @ref releaseswhen
|
|
- @ref releaseshow
|
|
|
|
@section releaseswhy Why Produce Releases?
|
|
|
|
The OpenOCD maintainers should produce releases periodically.
|
|
he reasons for several reasons that should be given in detail, before
|
|
explaining who and how the processes occur.
|
|
|
|
At any time, a "source archives" can be produced by running 'make dist'
|
|
in the OpenOCD project tree. With the 0.2.0 release, this command will
|
|
produce openocd-\<version\>.{tar.gz,tar.bz2,zip} archives, which will be
|
|
suitable for being released when produced properly.
|
|
|
|
When released for users, these archives present several important
|
|
advantages when contrasted to using the Subversion repository:
|
|
|
|
-# They allow others to package and distribute the code to users.
|
|
-# They build easier for developers, because they contain
|
|
a working configure script that was produced by the Release Manager.
|
|
-# They prevent users from trying a random HEAD revision of the trunk.
|
|
-# They free developers from answering questions about trunk breakage.
|
|
|
|
Hopefully, this shows several good reasons to produce regular releases,
|
|
but these release processes were developed with some additional design
|
|
goals in mind. Specifically, the releases processes should have the
|
|
following properties:
|
|
|
|
-# Produce successive sets of release archives cleanly and consistently.
|
|
- Implementable as a script that automates the critical release steps.
|
|
-# Prevent human operators from doing it wrong, as much as possible.
|
|
-# Allow scheduling and automation of release process milestones.
|
|
|
|
The current release processes are documented in the following sections.
|
|
They attempt to meet these design goals, but there are many improvements
|
|
remaining to be made toward automating the process.
|
|
|
|
@section releaseswho OpenOCD Release Manager
|
|
|
|
OpenOCD archive releases will be produced by an individual filling the
|
|
role of <i>Release Manager</i>. This individual determines the schdule
|
|
(@see releaseswhen) and executes the release processes for the
|
|
community. Each release requires one individual to fulfill this role,
|
|
and these processes should survive any such transition gracefully.
|
|
|
|
@section releaseswhen OpenOCD Release Schedule
|
|
|
|
The OpenOCD release process must be carried out on a periodic basis
|
|
in order to realize the benefits outlined above (@see releaseswhy).
|
|
|
|
Starting with the 0.2.0 release, the OpenOCD project should produce a
|
|
new minor release each month, with a major release once per year. Bug
|
|
fix releases could be provided more frequently; however, these should
|
|
not be a priority for the Release Manager until the processes have been
|
|
fully automated, to use resources most efficiently.
|
|
|
|
If T is the time of the next release, then the following milestones
|
|
describe the release milestones for each new release cycle.
|
|
|
|
- T minus one month: start of new development cycle
|
|
- T minus two weeks: announce pending trunk closure to new work
|
|
- T minus one week: close trunk to new work, begin testing phase
|
|
- T minus two days: call for final bug fixes
|
|
- T minus one day: produce -rc packages and distribute to testers
|
|
- T minus one hour: produce final packages and post on-line
|
|
|
|
The process of scheduling release milestones should be community driven,
|
|
though the Release Manager should attempt to follow these guidelines.
|
|
Specifically, missing features that were scheduled for a release should
|
|
be dropped, rather than delaying the release cycle to wait for them.
|
|
|
|
@section releaseshow Release Process: Step-by-Step
|
|
|
|
The exact process likely requires a few releases to work out the bugs,
|
|
as it will take some experience before a script can be developed and
|
|
tested that does everything safely and robustly. Even then, some steps
|
|
require clear user intervention -- and not only by the release manager.
|
|
|
|
-# Produce final patches to the trunk (or release branch):
|
|
- add NEWS item to describe the release changes? (not ready for 0.2.0)
|
|
- the community should try to help produce this material
|
|
- can be used to automatically post "blurbs" about the project.
|
|
- bump library version if our API changed (not yet required)
|
|
- bump package version
|
|
-# Produce and verify the binary packages:
|
|
-# Start with a clean working copy, used for producing releases only.
|
|
-# produce a ChangeLog for the release (using svn2cl).
|
|
-# bootstrap, configure, and build the package.
|
|
-# run 'make distcheck' to produce the distribution archives.
|
|
-# run 'make maintainer-clean'; verify the repository is empty again.
|
|
-# Branch or tag the required tree in the Subversion repository:
|
|
- For a major/minor release from the main trunk, branch and tag it:
|
|
-# svn cp .../trunk .../branches/${BRANCH_VERSION}
|
|
-# svn cp .../branches/${BRANCH_VERSION} .../tags/${PACKAGE_VERSION}
|
|
- For a bug-fix or final release from a release branch, only tag it:
|
|
-# svn cp .../branches/${BRANCH_VERSION} .../tags/${PACKAGE_VERSION}
|
|
- where:
|
|
- BRANCH_VERSION - is x.0.0-trunk or x.y.0-trunk
|
|
- PACKAGE_VERSION - is x.y.z
|
|
-# Upload packages and post announcements of their availability:
|
|
-# Release packages into files section of berliOS project site.
|
|
-# Post announcement e-mail to the openocd-development list.
|
|
-# After the community has checked their sanity, we can post "blurbs":
|
|
-# Post NEWS update to freshmeat.net and other trackers.
|
|
-# Submit big NEWS updates to news feeds (e.g. Digg, Reddit, etc.).
|
|
|
|
Totally-automated packaging and distribution of OpenOCD requires more
|
|
patching (post-0.2.0), but the final script(s) should be able to manage
|
|
most steps in these processes. The steps requiring user input can be
|
|
guided by an "assistant" that walks the Release Manager through the
|
|
process from beginning to end, performing basic sanity checks on their
|
|
various inputs (e.g. the NEWS blurb).
|
|
|
|
*/
|
|
/** @file
|
|
This file contains the @ref releases page.
|
|
*/
|