X-Git-Url: https://granicus.if.org/sourcecode?a=blobdiff_plain;f=ROADMAP;h=4c8078002e9725d7f11923879167a976e634a729;hb=58dbbce194bf3706c5dc024e2e0a93a59516de47;hp=e4efe87a54ad223b2273f19bc25cc5601cb7edad;hpb=f3a63ebc22c689254dbeb0763e1f636737b247ae;p=apache diff --git a/ROADMAP b/ROADMAP index e4efe87a54..4c8078002e 100644 --- a/ROADMAP +++ b/ROADMAP @@ -1,138 +1,6 @@ APACHE 2.x ROADMAP ================== -Last modified at [$Date: 2002/10/18 01:08:38 $] - - -INTRODUCTION ------------- -The Apache HTTP Server project must balance two competing and disjoint -objectives: maintain stable code for third party authors, distributors and -most importantly users so that bug and security fixes can be quickly adopted -without significant hardship due to API changes; and continue the development -process that requires ongoing redesign to work around earlier oversights in -the implementation of a fluid and flexible API. - -The Apache HTTP Server versions, through 2.0, used the Module Magic Number -to reflect the relatively frequent API changes. This had the shortcoming -of often leaving binary download users hunting to replace their loaded third -party modules. This left the third party module authors searching through -the API change histories to determine the new declarations, APIs and side -effects of making the necessary code changes. - -With the simultaneous release of Apache 2.2-stable and Apache 2.3-development, -the Apache HTTP Server project is moving to a more predictable stable code -branch, while opening the development to forward progress without concern -for breaking the stable branch. This document explains the rationale between -the two versions and their behavior, going forward. - - -STABLE RELEASES, 2.{even}.{revision} ------------------------------------- - -All even numbered releases will be considered stable revisions. - -Stable revisions will retain forward compatiblity to the maximum -possible extent. Features may be added during minor revisions, and -features may be deprecated by making appropriate notations in the -documentation, but no features may be removed. - -In essence, that implies that you can upgrade from one minor revision -to the next with a minimum of trouble. In particular, this means: - - * The Module API will retain forward compatibility. - It will not be necessary to update modules to work with new - revisions of the stable tree. - - * The run-time configuration will be forward compatible. - No configuration changes will be necessary to work with new - revisions of the stable tree. - - * Compile-time configuration will be forward compatible. - The configure command line options that work in one release - of the stable tree will also work in the next release. - -As always, it will be necessary to test any new release to assure -that it works correctly with a particular configuration and a -particular set of modules, but every effort will be made to assure -that upgrades are as smooth as possible. - -In addition, the following development restrictions will aid in -keeping the stable tree as safe as possible: - - * No 'Experimental' modules; while it may be possible (based on API changes - required to support a given module) to load a 2.3-development module into - a 2.2-stable build of Apache, there are no guarantees. Experimental - modules will be introduced to the 2.3-development versions and either - added to 2.2-stable once they are proven and compatible, or deferred - to the 2.4-stable release if they cannot be incorporated in the current - stable release due to API change requirements. - - * The stable CVS tree should not remain unstable at any time. Atomic commits - aught be used to introduce code from the development version to the stable - tree. At any given time a security release may be in preparation, - unbeknownst to other contributors. At any given time, testers may be - checking out CVS head to confirm that a bug has been corrected. And as - all code was well-tested in development prior to committing to the stable - tree, there is really no reason for this tree to be broken for more than - a few minutes during a lengthy commit. - - -DEVELOPMENT RELEASES, 2.{odd}.{revision} ------------------------------------------ -All odd numbered releases designate the 'next' possible stable release, -therefore the current development version will always be one greater than -the stable release. Work proceeds on development releases, permitting -the modification of the MMN at any time in order to correct deficiencies -or shortcomings in the API. This means that third party modules from one -revision to another may not be binary compatible, and may not successfully -compile without modification to accomodate the API changes. - -The only 'supported' development release at any time will be the most -recently released version. Developers will not be answering bug reports -of older development releases once a new release is available, it becomes -the resposibility of the reporter to use the latest development version -to confirm that the bug still exists. - -Any new code, new API features or new ('experimental') modules may be -promoted at any time to the next stable release, by a vote of the project -contributors. This vote is based on the technical stability of the new -code and the stability of the interface. Once moved to stable, that feature -cannot change for the remainder of that lifetime of that stable verions, -so the vote must reflect that the final decisions on the behavior and naming -of that new feature were reached. Vetos continue to apply to this choice -of introducing the new work to the stable version. - -At any given time, when the quality of changes to the development branch -is considered release quality, that version may become a candidate for the -next stable release. This includes some or all of the API changes, promoting -experimental modules to stable or deprecating and eliminating older modules -from the last stable release. All of these choices are considered by the -project as a group in the interests of promoting the stable release, so that -any given change may be 'deferred' for a future release by the group, rather -than introduce unacceptable risks to adopting the next stable release. - -Third party module authors are strongly encouraged to test with the latest -development version. This assures that the module will be ready for the next -stable release, but more importantly, the author can react to shortcomings -in the API early enough to warn the dev@httpd.apache.org community of the -shortcomings so that they can be addressed before the stable release. The -entire onus is on the third party module author to anticipate the needs of -their module before the stable release is created, once it has been released -they will be stuck with that API for the lifetime of that stable release. - - -ALL RELEASES ------------- -In order to avoid 'skipped' release numbers, the Release Manager will generally -roll a release candidate (APACHE_#_#_#_RC#) tag. This is true of both the -stable as well as the development tree. Release Candidate tarballs will be -announced to the stable-testers@httpd.apache.org for the stable tree, or to -the current-testers@httpd.apache.org list for the development tree. - -The final APACHE_#_#_# tag will not exist until the APACHE_#_#_#_RC# candidate -has passed the usual votes to release that version. Only then is the final -tarball packaged, removing all -rc# designations from the version number, and -tagging the tree with the release number. +Last modified at [$Date$] WORKS IN PROGRESS @@ -164,20 +32,6 @@ WORKS IN PROGRESS Remember, it just takes cvs diff -b (that is, --ignore-space-change) to see the code changes and ignore that cruft. Get editing Justin :) - * revamp the input filter syntax to provide for ordering of - filters created with the Set{Input|Output}Filter and the - Add{Input|Output}Filter directives. A 'relative to filterx' - syntax is definately preferable. - - * Platforms that do not support fork (primarily Win32 and AS/400) - Architect start-up code that avoids initializing all the modules - in the parent process on platforms that do not support fork. - - . Better yet - not only inform the startup of which phase it's in, - but allow the parent 'process' to initialize shared memory, etc, - and create a module-by-module stream to pass to the child, so the - parent can actually arbitrate the important stuff. - * Replace stat [deferred open] with open/fstat in directory_walk. Justin, Ian, OtherBill all interested in this. Implies setting up the apr_file_t member in request_rec, and having all modules use @@ -200,13 +54,15 @@ WORKS IN PROGRESS available for the life of the request, so a complete async implementation would need to happen 3.0 release. - * Add a string "class" that combines a char* with a length - and a reference count. This will help reduce the number - of strlen and strdup operations during request processing. - Including both the length and allocation will save us a ton - of reallocation we do today, in terms of string manipulation. - - OtherBill asks if this is really an APR issue, not an HTTPD issue? + Brian notes that async writes will provide a bigger + scalability win than async reads for most servers. + We may want to try a hybrid sync-read/async-write MPM + as a next step. This should be relatively easy to + build: start with the current worker or leader/followers + model, but hand off each response brigade to a "completion + thread" that multiplexes writes on many connections, so + that the worker thread doesn't have to wait around for + the sendfile to complete. MAKING APACHE REPOSITORY-AGNOSTIC @@ -335,7 +191,7 @@ MAKING APACHE REPOSITORY-AGNOSTIC than calling apr_dir_open/read/close(), a caller uses resource->repos->get_children() or somesuch. - Note that things like mod_dir, mod_autoindex, and mod_negotation + Note that things like mod_dir, mod_autoindex, and mod_negotiation need to be converted to use these mechanisms so that their functions will work on logical repositories rather than just filesystems.