|
Packit |
90a5c9 |
APACHE 2.x VERSIONING
|
|
Packit |
90a5c9 |
=====================
|
|
Packit |
90a5c9 |
[$LastChangedDate: 2007-02-28 17:12:06 +0000 (Wed, 28 Feb 2007) $]
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
INTRODUCTION
|
|
Packit |
90a5c9 |
------------
|
|
Packit |
90a5c9 |
The Apache HTTP Server project must balance two competing and disjoint
|
|
Packit |
90a5c9 |
objectives: maintain stable code for third party authors, distributors and
|
|
Packit |
90a5c9 |
most importantly users so that bug and security fixes can be quickly adopted
|
|
Packit |
90a5c9 |
without significant hardship due to user-visible changes; and continue the
|
|
Packit |
90a5c9 |
development process that requires ongoing redesign to correct earlier
|
|
Packit |
90a5c9 |
oversights and to add additional features.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The Apache HTTP Server, through version 2.0, used the Module Magic Number (MMN)
|
|
Packit |
90a5c9 |
to reflect API changes. This had the shortcoming of often leaving users
|
|
Packit |
90a5c9 |
hunting to replace binary third party modules that were now incompatible.
|
|
Packit |
90a5c9 |
This also left module authors searching through the API change histories to
|
|
Packit |
90a5c9 |
determine the exact cause for the MMN change and whether their module was
|
|
Packit |
90a5c9 |
affected.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
With the simultaneous release of Apache 2.2-stable and Apache 2.3-development,
|
|
Packit |
90a5c9 |
the Apache HTTP Server project is moving towards a more predictable stable
|
|
Packit |
90a5c9 |
release cycle, while allowing forward progress to occur without concern
|
|
Packit |
90a5c9 |
for breaking the stable branch. This document explains the rationale between
|
|
Packit |
90a5c9 |
the two versions and their behavior.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
STABLE RELEASES, 2.{even}.{revision}
|
|
Packit |
90a5c9 |
------------------------------------
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
All even numbered releases will be considered stable revisions.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Stable revisions will retain forward compatiblity to the maximum
|
|
Packit |
90a5c9 |
possible extent. Features may be added during minor revisions, and
|
|
Packit |
90a5c9 |
features may be deprecated by making appropriate notations in the
|
|
Packit |
90a5c9 |
documentation, but no features may be removed.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
In essence, that implies that you can upgrade from one minor revision
|
|
Packit |
90a5c9 |
to the next with a minimum of trouble. In particular, this means:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
* The Module API will retain forward compatibility.
|
|
Packit |
90a5c9 |
It will not be necessary to update modules to work with new
|
|
Packit |
90a5c9 |
revisions of the stable tree.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
* The run-time configuration will be forward compatible.
|
|
Packit |
90a5c9 |
No configuration changes will be necessary to work with new
|
|
Packit |
90a5c9 |
revisions of the stable tree.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
* Compile-time configuration will be forward compatible.
|
|
Packit |
90a5c9 |
The configure command line options that work in one release
|
|
Packit |
90a5c9 |
of the stable tree will also work in the next release.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
As always, it will be necessary to test any new release to assure
|
|
Packit |
90a5c9 |
that it works correctly with a particular configuration and a
|
|
Packit |
90a5c9 |
particular set of modules, but every effort will be made to assure
|
|
Packit |
90a5c9 |
that upgrades are as smooth as possible.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
In addition, the following development restrictions will aid in
|
|
Packit |
90a5c9 |
keeping the stable tree as safe as possible:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
* No 'Experimental' modules; while it may be possible (based on API changes
|
|
Packit |
90a5c9 |
required to support a given module) to load a 2.3-development module into
|
|
Packit |
90a5c9 |
a 2.2-stable build of Apache, there are no guarantees. Experimental
|
|
Packit |
90a5c9 |
modules will be introduced to the 2.3-development versions and either
|
|
Packit |
90a5c9 |
added to 2.2-stable once they are proven and compatible, or deferred
|
|
Packit |
90a5c9 |
to the 2.4-stable release if they cannot be incorporated in the current
|
|
Packit |
90a5c9 |
stable release due to API change requirements.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
* The stable subversion tree should not remain unstable at any time. Atomic
|
|
Packit |
90a5c9 |
commits ought be used to introduce code from the development version to the
|
|
Packit |
90a5c9 |
stable tree. At any given time a security release may be in preparation,
|
|
Packit |
90a5c9 |
unbeknownst to other contributors. At any given time, testers may be
|
|
Packit |
90a5c9 |
checking out SVN trunk to confirm that a bug has been corrected. And as
|
|
Packit |
90a5c9 |
all code was well-tested in development prior to committing to the stable
|
|
Packit |
90a5c9 |
tree, there is really no reason for this tree to be broken for more than
|
|
Packit |
90a5c9 |
a few minutes during a lengthy commit.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
In order to avoid 'skipped' release numbers in the stable releases, the
|
|
Packit |
90a5c9 |
Release Manager will generally roll a release candidate (APACHE_#_#_#_RC#)
|
|
Packit |
90a5c9 |
tag. Release Candidate tarballs will be announced to the
|
|
Packit |
90a5c9 |
stable-testers@httpd.apache.org for the stable tree. Then, the participants
|
|
Packit |
90a5c9 |
will vote on the quality of the proposed release tarball.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The final APACHE_#_#_# tag will not exist until the APACHE_#_#_#_RC# candidate
|
|
Packit |
90a5c9 |
has passed the usual votes to release that version. Only then is the final
|
|
Packit |
90a5c9 |
tarball packaged, removing all -rc# designations from the version number, and
|
|
Packit |
90a5c9 |
tagging the tree with the release number.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
DEVELOPMENT RELEASES, 2.{odd}.{revision}
|
|
Packit |
90a5c9 |
-----------------------------------------
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
All odd numbered releases designate the 'next' possible stable release,
|
|
Packit |
90a5c9 |
therefore the current development version will always be one greater than
|
|
Packit |
90a5c9 |
the current stable release. Work proceeds on development releases, permitting
|
|
Packit |
90a5c9 |
the modification of the MMN at any time in order to correct deficiencies
|
|
Packit |
90a5c9 |
or shortcomings in the API. This means that modules from one development
|
|
Packit |
90a5c9 |
release to another may not be binary compatible, or may not successfully
|
|
Packit |
90a5c9 |
compile without modification to accomodate the API changes.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The only 'supported' development release at any time will be the most
|
|
Packit |
90a5c9 |
recently released version. Developers will not be answering bug reports
|
|
Packit |
90a5c9 |
of older development releases once a new release is available. It becomes
|
|
Packit |
90a5c9 |
the resposibility of the reporter to use the latest development version
|
|
Packit |
90a5c9 |
to confirm that any issue still exists.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Any new code, new API features or new ('experimental') modules may be
|
|
Packit |
90a5c9 |
promoted at any time to the next stable release, by a vote of the project
|
|
Packit |
90a5c9 |
contributors. This vote is based on the technical stability of the new
|
|
Packit |
90a5c9 |
code and the stability of the interface. Once moved to stable, that feature
|
|
Packit |
90a5c9 |
cannot change for the remainder of that stable release cycle, so the vote must
|
|
Packit |
90a5c9 |
reflect that the final decisions on the behavior and naming of that new
|
|
Packit |
90a5c9 |
feature were reached. Vetos continue to apply to this choice of introducing
|
|
Packit |
90a5c9 |
the new work to the stable version.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
At any given time, when the quality of changes to the development branch
|
|
Packit |
90a5c9 |
is considered release quality, that version may become a candidate for the
|
|
Packit |
90a5c9 |
next stable release. This includes some or all of the API changes, promoting
|
|
Packit |
90a5c9 |
experimental modules to stable or deprecating and eliminating older modules
|
|
Packit |
90a5c9 |
from the last stable release. All of these choices are considered by the
|
|
Packit |
90a5c9 |
project as a group in the interests of promoting the stable release, so that
|
|
Packit |
90a5c9 |
any given change may be 'deferred' for a future release by the group, rather
|
|
Packit |
90a5c9 |
than introduce unacceptable risks to adopting the next stable release.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Third party module authors are strongly encouraged to test with the latest
|
|
Packit |
90a5c9 |
development version. This assures that the module will be ready for the next
|
|
Packit |
90a5c9 |
stable release, but more importantly, the author can react to shortcomings
|
|
Packit |
90a5c9 |
in the API early enough to warn the dev@httpd.apache.org community of the
|
|
Packit |
90a5c9 |
shortcomings so that they can be addressed before the stable release. The
|
|
Packit |
90a5c9 |
entire burden is on the module author to anticipate the needs of their module
|
|
Packit |
90a5c9 |
before the stable release is created. Once a new stable release cycle has
|
|
Packit |
90a5c9 |
begun, that API will be present for the lifetime of the stable release. Any
|
|
Packit |
90a5c9 |
desired changes in the stable versions must wait for inclusion into the next
|
|
Packit |
90a5c9 |
release cycle.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When deciding to promote a development tree to being stable, a determination
|
|
Packit |
90a5c9 |
should be made whether the changes since the last stable version warrant a
|
|
Packit |
90a5c9 |
major version bump. That is, if 2.2 is the current stable version and 2.3 is
|
|
Packit |
90a5c9 |
'ready' to become stable, the group needs to decide if the next stable
|
|
Packit |
90a5c9 |
version is 2.4 or 3.0. One suggested rule of thumb is that if it requires
|
|
Packit |
90a5c9 |
too much effort to port a module from 2.2 to 2.4, then the stable version
|
|
Packit |
90a5c9 |
should be labeled 3.0.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
In order to ease the burden of creating development releases, the process
|
|
Packit |
90a5c9 |
for packaging a development releases is less formal than for the stable
|
|
Packit |
90a5c9 |
release. This strategy reflects the fact that while in development, versions
|
|
Packit |
90a5c9 |
are cheap. Development releases may be classified as alpha, beta, or GA
|
|
Packit |
90a5c9 |
to reflect the group's perceived stability of the tree. Development releases
|
|
Packit |
90a5c9 |
may be made at any time by any committer.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Please read the following link for a more detailed description of the
|
|
Packit |
90a5c9 |
development release strategy:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
http://httpd.apache.org/dev/release.html
|