Essentials
Download!
Documentation
Get Involved
Subprojects
Miscellaneous
|
Introduction
|
This document describes the general release policies used by the
Apache HTTP Server Project to create releases of httpd-2.0 (the current
Apache 2.0 branch). As described herein, this policy is not set in stone
and may be adjusted by the Release Manager.
With the introduction of Apache 2.1, the Apache httpd project has
adopted an odd-even release strategy, where development happens with
alpha and beta releases assigned an odd-numbered minor version, and its
general availability (stable) release is designed with the subsequent
even-numbered minor version. E.g. 2.1.0-alpha through 2.1.6-alpha
were followed by 2.1.7-beta through 2.1.9 beta, and cumulated in the
2.2.0 general availability release.
|
Who can make a release?
|
Technically, anyone can make a release of the source code due to the
Apache Software License.
However, only members of the Apache HTTP Server Project (committers)
can make a release designated with Apache. Other people must
call their release something other than "Apache" unless they obtain
written permission from the Apache Software Foundation.
Following our official release policies, we will only accept release
binaries from members of the Apache HTTP Server Project for inclusion on our
website. This ensures that our binaries can be supported by members of
the project. Other people are free to make binaries, but we will not
post them on our website.
|
Who is in charge of a release?
|
The release is coordinated by the Release Manager (hereafter, abbreviated
as RM). Since this job requires coordination of the development community
(and access to subversion), only committers to the project can be RM. However,
there is no set RM. Any committer may perform a release at any time. In
order to facilitate communication, it is deemed nice to alert the
community with your planned release schedule before executing the
release. A release should only be made when there is a plan to publicly
release it. (A release must not be made only for private distribution).
|
Who may make a good candidate for an RM?
|
Someone with lots of time to kill. Being an RM is a very important job
in our community because it takes a fair amount of time to produce a stable
release. If you feel lucky, a release could be distributed without testing,
but our experience has shown that this leads to a higher number of dud
releases. In general, our experience has shown that a well-coordinated
release fares better than non-coordinated releases.
|
When do I know if it is a good time to release?
|
It is our convention to indicate showstoppers in the STATUS
file in the repository. A showstopper entry does not automatically
imply that a release can not be made. As the RM has final authority
on what makes it into a release, they can choose to ignore the entries.
An item being denoted as a showstopper indicates that the group
has come to a consensus that no further releases can be made until the
entry is resolved. These items may be bugs, outstanding vetos that have
not yet been resolved, or enhancements that must make it into the
release. Note that the RM may also add showstopper entries to indicate
what issues must be resolved before they intend to create a release.
|
What power does the RM yield?
|
Regarding what makes it into a release, the RM is the unquestioned
authority. No one can contest what makes it into the release. The
community will judge the release's quality after it has been issued,
but the community can not force the RM to include a feature that they
feel uncomfortable adding. Remember that this document is only a
guideline to the community and future RMs - each RM may run a release
in a different way. If you don't like what an RM is doing, start
preparing for your own competing release.
|
How does an impending release affect development?
|
It can not. Let's repeat that: an impending release can not affect
development of the project. It is the RM's responsibility to identify
what changes should make it into the release. The RM may have an
intermediate tag, so the RM can merge in or reject changes as they are
committed to the repository's HEAD.
Committers may voluntarily refrain from committing patches if
they wish to ease the burden on the RM, but they are under
no obligation to do so. This is one reason why we
recommend that the RMs have plenty of time on their hands - they may have to
deal with a rapidly changing target. It's not an easy job.
|
How can an RM be confident in a release?
|
The RM may perform sanity checks on release candidates. One highly
recommended suggestion is to run the httpd-test suite against the candidate.
The release candidate should pass all of the relevant tests before making
it official, and certainly avoid new regressions (tests that previously
passed, and now fail).
Another good idea is to coordinate running a candidate on apache.org for
a period of time. This will require coordination with the current
maintainers of apache.org's httpd instance. In the past, the group has
liked to see approximately 48-72 hours of usage in production to certify
that the release is functional in the real world. Note that some committers
may choose to not vote on a release until feedback has been gathered from the
apache.org instance running the release. This is not a requirement (each
committer is free to come up with their own personal voting guidelines),
but it produces a feeling of confidence in the release that it will not
be a dud.
|
How to do a release?
|
Once the tree has been suitably tested by the RM and any other interested
parties, they should "roll" a candidate tarball for potential release.
Key points:
- Execute
./build.sh all in case of the 2.0.x documentation and
./build.sh all convmap in case of the 2.2.x documentation to
ensure that the documentation transformations are up to date.
- Ensure that the RM's PGP/GPG key is in the httpd-dist/KEYS file.
- Set
AP_SERVER_DEVBUILD_BOOLEAN to 0 in
include/ap_release.h in case of 2.2.x and set
AP_SERVER_ADD_STRING to "" in case of 2.0.x.
- Create an official X.Y.Z tag based on the candidate tree.
- Revert the changes done to
include/ap_release.h and bump
AP_SERVER_PATCHLEVEL_NUMBER .
- Bump
ENTITY httpd.patch in
docs/manual/style/version.ent .
- Note the tag date in the STATUS file.
- Run the httpd/site/trunk/dist/tools/release.sh script.
- Copy the generated release tarballs and signatures to
people.apache.org:/www/httpd.apache.org/dev/dist.
- Email dev@httpd.apache.org, current-testers@httpd.apache.org and
stable-testers@httpd.apache.org with a [VOTE] Release X.Y.Z to call for
testing and votes on this candidate.
|
What can I call this release?
|
At this point, this tarball/archive is not yet a release.
Based on the communities confidence in the code, the next step is
to issue a release vote as alpha, beta or general availability (GA)
candidate. The Apache HTTP Server Project has three classifications
for its releases:
- Alpha
- Beta
- General Availability (GA)
Alpha indicates that the release is not meant for mainstream usage or
may have serious problems that prohibits its use. The initial releases
off of the x.{odd}.z development branches are considered alpha quality.
Beta indicates that the x.{odd}.z development branch is nearing
completion and will soon ship as a x.{even}.0 GA release. This indicates
that it is expected to compile and perform basic tasks. However, there
may be problems with this release that inhibit its widespread adoption.
General Availability (GA) indicates that this release is the best
available version and is recommended for all usage. It also indicates
that this release replaces all previous GA versions, and it's interfaces
should remain stable throughout the life of this x.y version. (Those
interfaces that are in flux are designated experimental.)
Finally, remember version numbers are cheap. If x.y.13 is retracted
due to a flaw or prior veto or simply because of 'one more change' to add
to this next release, then the RM should designate x.y.14. Don't attempt
to overload an earlier tarball with additional changes, simply keep moving.
|
Who can vote?
|
For the ASF to release the prepared tarball/archive, at least three
project members must vote affirmatively for release, and there must be more
positive than negative votes for the release. There is no 'veto' to a
release vote. A previous veto of specific code can and should be called
out to the RM if it was not honored, and it's the RM's decision to determine
that the veto included a justification and therefore retract the vote. A new
tarball release candidate should be rolled without the offending code if this
is the case.
Non-committers may cast a vote for a release's quality. In fact,
this is extremely encouraged as it provides much-needed feedback to
the community about the release's quality. However, only binding
votes casted by committers count towards the designation.
Finally, note that votes are on source code tarballs, and only the
source code is authoritative. Binaries, while helpful, are considered
other artifacts and must be generated from the exact source code contained
in the release. If a patch is unavoidable for a specific platform, the
applicable patches MUST be made available alongside the platform binaries.
|
How do we make it public?
|
Once the release has reached the highest-available designation (as deemed
by the RM), the release can be moved to the httpd distribution directory
on apache.org. It should be ensured that the release is also added to
Bugzilla by sending a mail to dev@httpd.apache.org requesting the same. The
request is picked up there by one of the project members with Bugzilla
administrator permissions and the release is added to Bugzilla. Also do
not forget to bump the version number in the projects doap file
(httpd/site/trunk/docs/doap.rdf ). Approximately
24 to 48 hours after the files have been moved, a public announcement can be
made. We wait this period so that the mirrors can receive the new release
before the announcement. An email can then be sent to the announcements lists
(announce@apache.org, announce@httpd.apache.org). Drafts of the announcement
are usually posted on the development list before sending the announcement to
let the community clarify any issues that we feel should be addressed in the
announcement.
|
Should the announcement wait for binaries?
|
In short, no. The only files that are required for a public release
are the source tarballs (.tar.Z, .tar.gz). Volunteers can provide
the Win32 source distribution and binaries, and other esoteric
binaries.
Note that the typical Win32 source distribution differs from the
original tarball in that it has generated project files as well as
the CRLF line endings required for that platform. More information
can be found here.
|
Oops. We found a problem.
|
At this point, the release has been created. No code changes can be
made in this release. If a problem is found, it will have to be addressed
in the next release or a patch can be made available. No changes can
be made between alpha, beta, and GA status. The only difference is the
file name that is downloaded by the users. If an alpha tarball is created,
but there was an error that can be resolved by re-rolling the tarball,
it may be permissible to re-roll the release. But, the code itself may
not change from designation to designation.
There are two courses of action:
Revoke the release and immediately create another one that has a fix
to this problem. You can take the old release, apply the single patch,
and start the voting process again. This is only recommended for
critical problems found early on in the release cycle.
If the problem is less severe, place the patch to the problem in the
/dist/httpd/patches/apply_to_X.Y.Z directory. A link to this directory
should be included in the release notes with descriptions as to what
problem each patch addresses.
|
Suggestions?
|
As always, if you have any suggestions or comments on our process,
please feel free to email our developer mailing list with your comments.
We hope you found this document useful.
|
|