← Back to branch summary

~ubuntu-branches/ubuntu/feisty/apache2/feisty

« back to all changes in this revision

Viewing changes to VERSIONING

  • Committer: Bazaar Package Importer
  • Author(s): Andreas Barth
  • Date: 2006-12-09 21:05:45 UTC
  • mfrom: (0.6.1 upstream)
  • Revision ID: james.westby@ubuntu.com-20061209210545-h70s0xaqc2v8vqr2
Tags: 2.2.3-3.2
http://bugs.debian.org/396265
* Non-maintainer upload.
* 043_ajp_connection_reuse: Patch from upstream Bugzilla, fixing a critical
  issue with regard to connection reuse in mod_proxy_ajp.
  Closes: #396265

Show diffs side-by-side

added added

removed removed

Lines of Context:
VERSIONING
 
1
APACHE 2.x VERSIONING
 
2
=====================
 
3
[$LastChangedDate: 2005-10-17 12:17:21 -0500 (Mon, 17 Oct 2005) $]
 
4
 
 
5
 
 
6
INTRODUCTION
 
7
------------
 
8
The Apache HTTP Server project must balance two competing and disjoint
 
9
objectives: maintain stable code for third party authors, distributors and
 
10
most importantly users so that bug and security fixes can be quickly adopted
 
11
without significant hardship due to user-visible changes; and continue the
 
12
development process that requires ongoing redesign to correct earlier
 
13
oversights and to add additional features.
 
14
 
 
15
The Apache HTTP Server, through version 2.0, used the Module Magic Number (MMN)
 
16
to reflect API changes.  This had the shortcoming of often leaving users
 
17
hunting to replace binary third party modules that were now incompatible.
 
18
This also left module authors searching through the API change histories to
 
19
determine the exact cause for the MMN change and whether their module was
 
20
affected.
 
21
 
 
22
With the simultaneous release of Apache 2.2-stable and Apache 2.3-development,
 
23
the Apache HTTP Server project is moving towards a more predictable stable
 
24
release cycle, while allowing forward progress to occur without concern
 
25
for breaking the stable branch.  This document explains the rationale between
 
26
the two versions and their behavior.
 
27
 
 
28
 
 
29
STABLE RELEASES, 2.{even}.{revision}
 
30
------------------------------------ 
 
31
 
 
32
All even numbered releases will be considered stable revisions. 
 
33
 
 
34
Stable revisions will retain forward compatiblity to the maximum
 
35
possible extent.  Features may be added during minor revisions, and
 
36
features may be deprecated by making appropriate notations in the
 
37
documentation, but no features may be removed.
 
38
 
 
39
In essence, that implies that you can upgrade from one minor revision
 
40
to the next with a minimum of trouble.  In particular, this means:
 
41
 
 
42
  * The Module API will retain forward compatibility.
 
43
    It will not be necessary to update modules to work with new
 
44
    revisions of the stable tree.
 
45
 
 
46
  * The run-time configuration will be forward compatible.
 
47
    No configuration changes will be necessary to work with new
 
48
    revisions of the stable tree.
 
49
 
 
50
  * Compile-time configuration will be forward compatible.
 
51
    The configure command line options that work in one release
 
52
    of the stable tree will also work in the next release.
 
53
 
 
54
As always, it will be necessary to test any new release to assure
 
55
that it works correctly with a particular configuration and a 
 
56
particular set of modules, but every effort will be made to assure
 
57
that upgrades are as smooth as possible.
 
58
 
 
59
In addition, the following development restrictions will aid in 
 
60
keeping the stable tree as safe as possible:
 
61
 
 
62
  * No 'Experimental' modules; while it may be possible (based on API changes
 
63
    required to support a given module) to load a 2.3-development module into
 
64
    a 2.2-stable build of Apache, there are no guarantees.  Experimental 
 
65
    modules will be introduced to the 2.3-development versions and either
 
66
    added to 2.2-stable once they are proven and compatible, or deferred
 
67
    to the 2.4-stable release if they cannot be incorporated in the current
 
68
    stable release due to API change requirements.
 
69
 
 
70
  * The stable subversion tree should not remain unstable at any time.  Atomic 
 
71
    commits aught be used to introduce code from the development version to the 
 
72
    stable  tree.  At any given time a security release may be in preparation, 
 
73
    unbeknownst to other contributors.  At any given time, testers may be
 
74
    checking out SVN trunk to confirm that a bug has been corrected.  And as
 
75
    all code was well-tested in development prior to committing to the stable
 
76
    tree, there is really no reason for this tree to be broken for more than 
 
77
    a few minutes during a lengthy commit.
 
78
 
 
79
In order to avoid 'skipped' release numbers in the stable releases, the
 
80
Release Manager will generally roll a release candidate (APACHE_#_#_#_RC#)
 
81
tag.  Release Candidate tarballs will be announced to the
 
82
stable-testers@httpd.apache.org for the stable tree.  Then, the participants
 
83
will vote on the quality of the proposed release tarball.
 
84
 
 
85
The final APACHE_#_#_# tag will not exist until the APACHE_#_#_#_RC# candidate
 
86
has passed the usual votes to release that version.  Only then is the final
 
87
tarball packaged, removing all -rc# designations from the version number, and
 
88
tagging the tree with the release number.
 
89
 
 
90
DEVELOPMENT RELEASES, 2.{odd}.{revision}
 
91
-----------------------------------------
 
92
 
 
93
All odd numbered releases designate the 'next' possible stable release,
 
94
therefore the current development version will always be one greater than
 
95
the current stable release.  Work proceeds on development releases, permitting
 
96
the modification of the MMN at any time in order to correct deficiencies 
 
97
or shortcomings in the API.  This means that modules from one development
 
98
release to another may not be binary compatible, or may not successfully
 
99
compile without modification to accomodate the API changes.
 
100
 
 
101
The only 'supported' development release at any time will be the most
 
102
recently released version.  Developers will not be answering bug reports
 
103
of older development releases once a new release is available.  It becomes
 
104
the resposibility of the reporter to use the latest development version
 
105
to confirm that any issue still exists.
 
106
 
 
107
Any new code, new API features or new ('experimental') modules may be
 
108
promoted at any time to the next stable release, by a vote of the project
 
109
contributors.  This vote is based on the technical stability of the new
 
110
code and the stability of the interface.  Once moved to stable, that feature
 
111
cannot change for the remainder of that stable release cycle, so the vote must
 
112
reflect that the final decisions on the behavior and naming of that new
 
113
feature were reached.  Vetos continue to apply to this choice of introducing
 
114
the new work to the stable version.
 
115
 
 
116
At any given time, when the quality of changes to the development branch
 
117
is considered release quality, that version may become a candidate for the
 
118
next stable release.  This includes some or all of the API changes, promoting
 
119
experimental modules to stable or deprecating and eliminating older modules
 
120
from the last stable release.  All of these choices are considered by the
 
121
project as a group in the interests of promoting the stable release, so that
 
122
any given change may be 'deferred' for a future release by the group, rather 
 
123
than introduce unacceptable risks to adopting the next stable release.
 
124
 
 
125
Third party module authors are strongly encouraged to test with the latest
 
126
development version.  This assures that the module will be ready for the next
 
127
stable release, but more importantly, the author can react to shortcomings
 
128
in the API early enough to warn the dev@httpd.apache.org community of the
 
129
shortcomings so that they can be addressed before the stable release.  The
 
130
entire burden is on the module author to anticipate the needs of their module
 
131
before the stable release is created.  Once a new stable release cycle has
 
132
begun, that API will be present for the lifetime of the stable release.  Any
 
133
desired changes in the stable versions must wait for inclusion into the next
 
134
release cycle.
 
135
 
 
136
When deciding to promote a development tree to being stable, a determination
 
137
should be made whether the changes since the last stable version warrant a
 
138
major version bump.  That is, if 2.2 is the current stable version and 2.3 is
 
139
'ready' to become stable, the group needs to decide if the next stable
 
140
version is 2.4 or 3.0.  One suggested rule of thumb is that if it requires
 
141
too much effort to port a module from 2.2 to 2.4, then the stable version
 
142
should be labeled 3.0.
 
143
 
 
144
In order to ease the burden of creating development releases, the process
 
145
for packaging a development releases is less formal than for the stable
 
146
release.  This strategy reflects the fact that while in development, versions
 
147
are cheap.  Development releases may be classified as alpha, beta, or GA
 
148
to reflect the group's perceived stability of the tree.  Development releases
 
149
may be made at any time by any committer.
 
150
 
 
151
Please read the following link for a more detailed description of the
 
152
development release strategy:
 
153
 
 
154
http://httpd.apache.org/dev/release.html