httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <>
Subject Re: A suggested ROADMAP for working 2.1/2.2 forward?
Date Thu, 17 Oct 2002 23:14:04 GMT
My user only comments sprinkled below...

On Fri, 2002-10-18 at 02:10, William A. Rowe, Jr. wrote:

> STABLE RELEASES, 2.{odd}.{revision}
> ------------------------------------
> All even numbered releases will be considered stable revisions.  That means;

You really meant odd in the above sentence, right?

>   * Forward Compatibility; users are not be required to find new downloads of 
>     currently loaded modules to upgrade from another revisions of the same 
>     version.  To upgrade from 2.1.0 and 2.1.27 will require no new modules.  
>     However, the third party modules may break from buggy code, or code that 
>     used an undocumented side effect of an API call, which may be changed to 
>     close bugs or security vulnerabilities.  Modules should be retested.
>     Moreover, new APIs may be introduced within the lifespan of the release,
>     and it is up to the third party module author to call out what version
>     forward this module is compatible with (e.g. "Compatible with Apache
>     HTTP Server version 2.1.12 and foward.")  The next stable release that 
>     causes module incompatibility for 2.1.x users will be an upgrade to
>     either the current 2.2.x-development releases or the 2.3.0-stable release.

OK, no more MMN bumps in the stable branch. Sounds good.

>   * No Deprecated modules; although new modules may be introduced within the
>     stable release, no loadable modules or their directives will be removed
>     within the lifetime of a given stable release version.  The next release 
>     that deprecates old modules for 2.1.x users will be an upgrade to either
>     the 2.2.x-development release or the 2.3.0-stable release.  
>   * Warnings should be provided in the documentation to give users a heads up
>     that a given module or directive will disappear in the future release,
>     and advise developers that a given API will change.  However, it is always
>     best to check the corresponding development release to determine the full
>     impact of such changes.

This is almost like Java API's. I like.

>   * No 'Experimental' modules; while it may be possible (based on API changes
>     required to support a given module) to load a 2.2-development module into
>     a 2.1-stable build of Apache, there are no guarantees.  Experimental 
>     modules will be introduced to the 2.2-development versions and either
>     added to 2.1-stable once they are proven and compatible, or deferred
>     to the 2.3-stable release if they cannot be incorporated in the current
>     stable release due to API change requirements.

Hmm, I'm not sure how this is going to work given that unstable code
will be different then stable code. Something that works perfectly in
2.2.x might break in 2.1.x. You really should roll pre-releases and
release candidates in the stable branch so that people can test. I think
current Linux 2.4.x development is an excellent example here.

>   * The stable CVS tree must not remain unstable at any time.  Atomic commits 
>     must 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.

Huh, this sounds very unrealistic. I'd say it's better to make sure that
the stable RELEASE is stable. CVS might break, maybe not even compile on
occasion. That's what the pre-releases and release candidates are for.

> DEVELOPMENT RELEASES, 2.{even}.{revision}
> -----------------------------------------
> All even numbered releases designate the 'next' possible stable release,
> therefore te 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.

Now if you keep changing the interfaces in the development version and
you develop experimental modules for it, there will be porting to the
stable branch involved. And that means bugs which have to be tested in
pre-releases and release candidates.

> 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 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.

Which makes my point more clear:

- have pre-releases (-preX)
- have release candidates (-rcX)


View raw message