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