You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/10/17 18:10:25 UTC
A suggested ROADMAP for working 2.1/2.2 forward?
APACHE 2.x ROADMAP
==================
Last modified at [$Date: 2002/10/01 19:13:06 $]
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.1-stable and Apache 2.2-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 rational between
the two versions and their behavior, going forward.
STABLE RELEASES, 2.{odd}.{revision}
------------------------------------
All even numbered releases will be considered stable revisions. That means;
* 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.
* 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.
* 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.
* 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.
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.
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.
BINARY PACKAGES
---------------
All emphasis will be focused on providing binary packages of stable release
versions. While they are a volunteer effort, and the project makes them
available only as a convenience and not on demand, the project will frown
on contributors providing development release binary packages when there
are no available binary packages available for the current stable release
for the platform in question.
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 12:03 PM 10/17/2002, Jeff Trawick wrote:
>"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
>
>> BINARY PACKAGES
>> ---------------
>> All emphasis will be focused on providing binary packages of stable release
>> versions. While they are a volunteer effort, and the project makes them
>> available only as a convenience and not on demand, the project will frown
>> on contributors providing development release binary packages when there
>> are no available binary packages available for the current stable release
>> for the platform in question.
>
>if I volunteer to provide a binbuild for a development release for a
>certain platform and don't volunteer to provide a binbuild for a
>stable release, anybody who frowns can kiss my ass
:-) I'd be happy to delete that paragraph. Remember tho... it's only the
project who looks bad, not you :-)
Agreed, this section can get lost for a while until someone wants to
take it up. Deleted.
Bill
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Jeff Stuart <js...@computer-city.net>.
On Thu, 2002-10-17 at 12:48, William A. Rowe, Jr. wrote:
> At 11:34 AM 10/17/2002, Jeff Stuart wrote:
> >On Thu, 2002-10-17 at 12:10, William A. Rowe, Jr. wrote:
> >> APACHE 2.x ROADMAP
> >> ==================
> >> Last modified at [$Date: 2002/10/01 19:13:06 $]
> >[...rest of the roadmap deleted...]
> >
> >If I may make 3 suggestions.
> >
> >1) If we want to match the kernel/perl versioning system, then make 2.2
> >the stable version and make 2.3 the devel version and just SKIP 2.1. :)
>
> Nope... for this reason. 2.0 was never 'stable' by this new definition. So we
> can consider that 2.0 was a development branch for it's entire life. Not that
> it was bad code, but we changed things many times. Now 2.1 we state that
> the odds never change. Actually matches 1.3 well (it no longer changes and
> hasn't since 1.3.14. Talk about a great track record :-)
>
> This is not linux/perl, in that we don't have the same even/odds. But it's
> pretty nice that when we start 3.0, it too will be development, and when we
> are ready, we fall nicely into the 3.1/3.2 pattern all over again.
>
> >2) THROW CVS out and switch over to using Subversion as the SCM for
> >Apache. Tags/branches are EASY to do! :) Besides, it USES apache 2.0
> >for the remote repository access. What better way to promote both
> >programs? :)
>
> That's a seperate topic :-) But a good point. Are we anywhere near ready?
> If we debate this, please pull out this point as subject: "SVN already?"
>
> >3) Possibly add in the roadmap something about using -pr and -rc
> >versions for testing before release. Especially on the stable branches.
>
> Absolutely. I sort of called that out by suggesting the _worktag (for use
> by everyone,) then the_RC# (only to be tweaked by the RM.)
>
> I could say more, but do you want to offer an edit instead?
>
> Bill
Well... Umm... It's not needed. LOL...
#1 wasn't all that "important" to me. It was "if we want to follow..."
type thing. :)
#2 of course is as you point out a seperate discussion.
#3 Hmm... I'm not sure if that even belongs in the roadmap now that I
think about it. That's more just the guidelines for the RM. More I
think about it... that's a guideline/suggestion for the RM.
--
Jeff Stuart <js...@computer-city.net>
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 11:34 AM 10/17/2002, Jeff Stuart wrote:
>On Thu, 2002-10-17 at 12:10, William A. Rowe, Jr. wrote:
>> APACHE 2.x ROADMAP
>> ==================
>> Last modified at [$Date: 2002/10/01 19:13:06 $]
>[...rest of the roadmap deleted...]
>
>If I may make 3 suggestions.
>
>1) If we want to match the kernel/perl versioning system, then make 2.2
>the stable version and make 2.3 the devel version and just SKIP 2.1. :)
Nope... for this reason. 2.0 was never 'stable' by this new definition. So we
can consider that 2.0 was a development branch for it's entire life. Not that
it was bad code, but we changed things many times. Now 2.1 we state that
the odds never change. Actually matches 1.3 well (it no longer changes and
hasn't since 1.3.14. Talk about a great track record :-)
This is not linux/perl, in that we don't have the same even/odds. But it's
pretty nice that when we start 3.0, it too will be development, and when we
are ready, we fall nicely into the 3.1/3.2 pattern all over again.
>2) THROW CVS out and switch over to using Subversion as the SCM for
>Apache. Tags/branches are EASY to do! :) Besides, it USES apache 2.0
>for the remote repository access. What better way to promote both
>programs? :)
That's a seperate topic :-) But a good point. Are we anywhere near ready?
If we debate this, please pull out this point as subject: "SVN already?"
>3) Possibly add in the roadmap something about using -pr and -rc
>versions for testing before release. Especially on the stable branches.
Absolutely. I sort of called that out by suggesting the _worktag (for use
by everyone,) then the_RC# (only to be tweaked by the RM.)
I could say more, but do you want to offer an edit instead?
Bill
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Joshua Slive <jo...@slive.ca>.
William A. Rowe, Jr. wrote:
>
> One bit concerns me, we cannot state that "we will break MMN compat
> between security fixes" and "modules are always forward compatible
> within a version (e.g. 2.1).
>
I agree that is a conflict, and I can't really decide which way I favor.
It seems attractive to say that we will bump the minor version number
(in Major.Minor.Revision style) whenever we lose forward-compatibility.
But then we could wind up with weird things like having to bump from
2.2.x to 2.4.0, but not integrate the changes from 2.3.x (because they
are not ready for stable). That would be way too confusing.
I guess I therefore lean towards saying that we will maintain as much
foward compatibility as possible within a Minor version, but we will
break it if necessary.
(One other alternative would be to call the unstable tree 3.x. Then
each time 3.x becomes stable we pull it into 2.x and start again with
3.(x+1). When we want a Major revision to stable we call it 4.0. I'm
guessing that is a little too big a numerical leap for most people to
think about.)
Joshua.
RE: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 12:32 PM 10/17/2002, Bill Stoddard wrote:
>> One way to summarize this would be: upgrading from a stable release to
>> the next minor number should be painless:
>> config.nice
>> make
>> make install
>> apachectl restart
>>
>> That implies:
>> - No non-backwards compatible config changes (runtime or compile-time)
>> - No removing modules ("deprecating" is fine; that means "to discourage
>> use of", not "to remove")
>> - No MMN changes
>>
>> These rules shouldn't be set in stone: if a security fix or other
>> crucial bug fix requires a MMN change, then so be it. These should just
>> be guidelines.
>>
>> Joshua.
>>
>
>+1 on all of Joshua's comments.
+1 here, too. Joshua, care to encapsulate this thought in ROADMAP?
One bit concerns me, we cannot state that "we will break MMN compat
between security fixes" and "modules are always forward compatible
within a version (e.g. 2.1).
So we have two options;
*) make the bar for breaking the MMN very, very high. I really have never
seen where an MMN *must* have been bumped for a security fix. However,
I agree it could happen.
*) upon such a (very rare) change, do we release the next 2.odd/2.even pair?
The odds are so unlikely I'd suggest we can go with #2. Even the big changes
for Win32 shellcode/PATH_INFO argument fixes were an internal API change,
not external, and that's the biggest security reorg I've seen in a long time.
Bill
RE: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> >
> >
> > STABLE RELEASES, 2.{odd}.{revision}
> > ------------------------------------
> > All even numbered releases will be considered stable revisions. That
> > means;
>
>
> One way to summarize this would be: upgrading from a stable release to
> the next minor number should be painless:
> config.nice
> make
> make install
> apachectl restart
>
> That implies:
> - No non-backwards compatible config changes (runtime or compile-time)
> - No removing modules ("deprecating" is fine; that means "to discourage
> use of", not "to remove")
> - No MMN changes
>
> These rules shouldn't be set in stone: if a security fix or other
> crucial bug fix requires a MMN change, then so be it. These should just
> be guidelines.
>
> Joshua.
>
+1 on all of Joshua's comments.
Bill
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Joshua Slive <jo...@slive.ca>.
William A. Rowe, Jr. wrote:
>
>
> STABLE RELEASES, 2.{odd}.{revision}
> ------------------------------------
> All even numbered releases will be considered stable revisions. That
> means;
One way to summarize this would be: upgrading from a stable release to
the next minor number should be painless:
config.nice
make
make install
apachectl restart
That implies:
- No non-backwards compatible config changes (runtime or compile-time)
- No removing modules ("deprecating" is fine; that means "to discourage
use of", not "to remove")
- No MMN changes
These rules shouldn't be set in stone: if a security fix or other
crucial bug fix requires a MMN change, then so be it. These should just
be guidelines.
Joshua.
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Bojan Smojver <bo...@rexursive.com>.
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 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.
Which makes my point more clear:
- have pre-releases (-preX)
- have release candidates (-rcX)
Bojan
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> APACHE 2.x ROADMAP
> ==================
> Last modified at [$Date: 2002/10/01 19:13:06 $]
In general I think this is very positive and sends the right message
to the user community... I separated any significant concerns into a
previous post :) I'm staying out of the version number issue, so this
isn't an endorsement or a complaint about your numering choice.
As far as modules in the experimental directory: I for one would want
mod_ext_filter in stable ASAP; a number of people seem to rely on it.
My hope is that we don't allow a development to go for years before it
becomes stable; otherwise, there is more pressure to move features or
extensive fixes to the existing stable tree, which means more churn,
more potential breakage, and more work required to maintain it. We'll
need to move to a new stable release (2.2?) in no more than 9 months.
We shouldn't postpone moving up to APR 1.x any longer than that.
Of course, bleeding edge development has to be allowed to proceed to
without screwing up the timeline for stuff like moving to APR 1.x or
the auth rework or whatever.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> BINARY PACKAGES
> ---------------
> All emphasis will be focused on providing binary packages of stable release
> versions. While they are a volunteer effort, and the project makes them
> available only as a convenience and not on demand, the project will frown
> on contributors providing development release binary packages when there
> are no available binary packages available for the current stable release
> for the platform in question.
if I volunteer to provide a binbuild for a development release for a
certain platform and don't volunteer to provide a binbuild for a
stable release, anybody who frowns can kiss my ass
best wishes,
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Jeff Stuart <js...@computer-city.net>.
On Thu, 2002-10-17 at 12:10, William A. Rowe, Jr. wrote:
> APACHE 2.x ROADMAP
> ==================
> Last modified at [$Date: 2002/10/01 19:13:06 $]
[...rest of the roadmap deleted...]
If I may make 3 suggestions.
1) If we want to match the kernel/perl versioning system, then make 2.2
the stable version and make 2.3 the devel version and just SKIP 2.1. :)
2) THROW CVS out and switch over to using Subversion as the SCM for
Apache. Tags/branches are EASY to do! :) Besides, it USES apache 2.0
for the remote repository access. What better way to promote both
programs? :)
3) Possibly add in the roadmap something about using -pr and -rc
versions for testing before release. Especially on the stable branches.
--
Jeff Stuart <js...@computer-city.net>
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 05:47 PM 10/17/2002, Andrew Ho wrote:
>I personally think maintaining stable/dev branches is a fine idea. I like
>the x.0 rationale for keeping even numbered versions development, and it
>also fits with Apache 1.3.x... but I also think it could be confusing if
>many other open source projects use odd numbered versions for development
>and Apache is the exception. And while I'm not by any means a core Apache
>developer I agree it seems a little premature to vote on this change right
>this instant.
The ROADMAP is progressing, but that doesn't mean it will ever be adopted.
Obviously everyone doesn't have cycles right now, or wants to see what
direction folks are trying to take this.
It needs some discussion. The critical juncture comes up when someone
wants to pull a release. Since that is a few weeks off, I don't think we will
jump to premature judgement, but make sure that everyone is heard over
the next week or few.
Bill
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by "Paul J. Reder" <re...@remulak.net>.
Bojan Smojver wrote:
> Quoting Glenn <gs...@gluelogic.com>:
>
>
>>-0.5 to using odd for stable, and even for development
>>
>>The model of parallel stable and development branches is similar to
>>numerous other projects, including the Linux kernel and Perl, except that
>>the meaning of the sub-version numbers is **reversed** in Bill's proposal.
>>While I am not saying we should copy the Linux and Perl versioning "just
>>because", I am suggesting that it is counter-intuitive and confusing to
>>end-users (and suits!) who are familiar with them. Therefore, I would
>>like to see X.even == stable and X.odd == development.
>>
>
> To me, as an Apache user (and would-be developer), this makes sense. Why not tag
> the current CVS head as 2.1.0 (unstable) and then work towards a stable 2.2?
> This would achieve two goals within the user/developer community:
>
> - show them that the versioning system changed and give them time to get used to
> it by spreading the word
>
> - let them now that the time to break the API is now, if they want the change to
> appear in the next stable release
>
> - look forward (positively) to the next "stable stable" release, which will even
> guarantee a great deal of binary compatibility
>
> - make significant psychological impact with 2.2 as compared to 2.0, which would
> convey the meaning of "stable stable" release more convincingly
>
> - let them know that the moment 2.2 has settled, the new development branch will
> be created (2.3)
>
Okay, I finally caught up on all this. Here's my 2 cents worth...
I am *very* much in favor of providing a stable location to make 3rd party
developers and end users comfortable while providing a parallel dev location for
the new and possibly unstable work to be happening.
With a small amount of cleanup/polish, I think the ROADMAP looks great. We can
hash out the details over the next days/weeks.
I also agree with Bojan above, but would like to offer one added twist...
there is some question about odd=stable vs. even=stable. I would submit that we
go with the following:
X.0.y = wild, wooly, no-holds-barred, pie-in-the-sky, dreamland. Feel free
to completely redesign the world, introduce new models, change the
whole way internals work, whatever...
Then, when the dust starts to settle and the wild becomes more mild...
X.1.y = Becomes the first serious development stream. We have a direction,
a solid base to build from, and a certain level of stability for
developers to trust. Things can change (including APIs and MMN), but
there are some limits (i.e. 2.1 would not decide to use another
portability layer...)
From that point on X.odd.y=dev, X.even.y=stable and follows the rules of
the ROADMAP...
X.0.y is always special because it signifies a dramatic shift in concepts for
a product. Handling X.0.y in the way described above officially recognizes why
most people are leary of X.0.y releases. It gives folks the opportunity to have
total freedom of design. Then, once there has been a proof of concept, the
prototype is working well, and there is a clear direction, we move it into an
official X.1.y development stream. In *theory* we could start a new X+1.0.y
stream as soom as we create a X.1.y stream.
In essence, this is how 2.0 came about. Several different sandboxes existed. Once
things settled down and we decided on Apache+APR, that became the development path.
The difference is, according to my comments above, we should have moved to 2.1
when 2.0 became an acceptable and stable proof of concept with a clear direction.
Our first GA would have resulted in creation of 2.2-stable and 2.3-dev.
Anyway, the long and short of it is, I like the parallel streams, I like the
rules setup in the ROADMAP, I like odd=dev and even=stable, and I like officially
recognizing the wild, unstable, and fun nature of X.0.y.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Bojan Smojver <bo...@rexursive.com>:
> This would achieve two goals within the user/developer community:
Concentrate Bojan... 1, 2, 3, 4, 5. Got it! Five goals :-)
Bojan
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Glenn <gs...@gluelogic.com>:
> -0.5 to using odd for stable, and even for development
>
> The model of parallel stable and development branches is similar to
> numerous other projects, including the Linux kernel and Perl, except that
> the meaning of the sub-version numbers is **reversed** in Bill's proposal.
> While I am not saying we should copy the Linux and Perl versioning "just
> because", I am suggesting that it is counter-intuitive and confusing to
> end-users (and suits!) who are familiar with them. Therefore, I would
> like to see X.even == stable and X.odd == development.
To me, as an Apache user (and would-be developer), this makes sense. Why not tag
the current CVS head as 2.1.0 (unstable) and then work towards a stable 2.2?
This would achieve two goals within the user/developer community:
- show them that the versioning system changed and give them time to get used to
it by spreading the word
- let them now that the time to break the API is now, if they want the change to
appear in the next stable release
- look forward (positively) to the next "stable stable" release, which will even
guarantee a great deal of binary compatibility
- make significant psychological impact with 2.2 as compared to 2.0, which would
convey the meaning of "stable stable" release more convincingly
- let them know that the moment 2.2 has settled, the new development branch will
be created (2.3)
I reckon one of the main reasons for slow Apache 2 adoption is the fact that PHP
and Perl are still in their early stages of offically supporting it. So, maybe
it would be a good idea to target 2.2 to be released in some sort of loose
coordination with those projects. Jakarta has excellent support for Apache 2
(mod_jk - stable, mod_jk2- beta, I think), so that should be already covered.
All this, together with its own performance and scaleability improvements, would
give Apache 2.2 a much better chance to grab serious numbers quickly.
Bojan
PS. Current RedHat Rawhide has 2.0.40 in it and no traces of 1.3.x. This is
excellent news!
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Glenn <gs...@gluelogic.com>.
I just caught up on the torrent of emails to this list. :-)
My understanding of the major issues which may aid Apache2 adoption:
- avoid breaking user configuration files between releases
- avoid breaking 3rd party modules between releases
- present clearer meaning of version numbers to those external to
Apache development
At the same time, it is important to keep the Apache project fun for
developers, which includes (whenever possible) not blocking developers
from playing and not blocking progress of the Apache project.
I had opposed a 2.1 for the auth modules because it didn't fit well with
my understanding of the way Apache development worked at the time. Since
we're discussing modifying the versioning of development on the whole, my
choice is different. Bill's proposal goes a long way towards addressing
the issues above.
+1 to concurrent stable and development branches
-0.5 to using odd for stable, and even for development
The model of parallel stable and development branches is similar to
numerous other projects, including the Linux kernel and Perl, except that
the meaning of the sub-version numbers is **reversed** in Bill's proposal.
While I am not saying we should copy the Linux and Perl versioning "just
because", I am suggesting that it is counter-intuitive and confusing to
end-users (and suits!) who are familiar with them. Therefore, I would
like to see X.even == stable and X.odd == development.
-Glenn
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Andrew Ho <an...@tellme.com>.
Hello,
Am I the only person confused by this?
WR>STABLE RELEASES, 2.{odd}.{revision}
WR>------------------------------------
WR>All even numbered releases will be considered stable revisions.
WR>DEVELOPMENT RELEASES, 2.{even}.{revision}
WR>-----------------------------------------
WR>All even numbered releases designate the 'next' possible stable release,
WR>therefore te current development version will always be one greater than
WR>the stable release.
Is the former sentence a typo? Shouldn't that say "All odd numbered
releases" under the "STABLE RELEASES" header?
I personally think maintaining stable/dev branches is a fine idea. I like
the x.0 rationale for keeping even numbered versions development, and it
also fits with Apache 1.3.x... but I also think it could be confusing if
many other open source projects use odd numbered versions for development
and Apache is the exception. And while I'm not by any means a core Apache
developer I agree it seems a little premature to vote on this change right
this instant.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer info@tellme.com Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101
----------------------------------------------------------------------
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Scott Hess <sc...@avantgo.com>.
On Thu, 17 Oct 2002, William A. Rowe, Jr. wrote:
> With the simultaneous release of Apache 2.1-stable and Apache
> 2.2-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 rational between the two versions and their behavior, going
> forward.
This is great. I'm our "Apache guy", and 2.0 has been a non-starter. I
can fairly easily keep up with the 1.3 changes, because it doesn't involve
revision to our codebase, so we get the best of both worlds. What I think
this arrangement would allow me to do is make local adjustments to our 2.1
codebase, and if they prove out in production, I can repackage them as a
patch to 2.2. Right now, the likelihood that I'll contribute to the most
current development tree is nil, because it's just too different from
where most of my work is done.
Excellent,
scott
RE: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Ask Bjoern Hansen <as...@develooper.com>.
On Thu, 17 Oct 2002, Bill Stoddard wrote:
> * Consider using the Linux versioning system... stable release is 2.x where
> x >0 and x == even. Developmemt release is 2.x where x is odd.
+100.
The Apache HTTPd versioning system has been plenty confusing to
people not following the httpd related ASF lists. Please make it
stop.
We did call Apache 2.0 stable, so the argument that 2.0 wasn't
stable so 2.{even} should be unstable seems pretty bogus to me.
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
RE: A suggested ROADMAP for working 2.1/2.2 forward?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Justin, I think this answers most of your questions?
Comments:
* +1, this is an extremely good start to drafting the rules for working on
stable releases. I could quibble with a point or two but this captures the
spirit nicely.
* Activity in the stable release would be limited to security and high
impact bug fixes and perhaps the occasional new function. Effort to
maintain the stable release should be minimal. This give us freedom to
continue to work on the 2.* development code base while providing users and
third party module developers some incentive to invest in the 2.0 codebase.
* Consider using the Linux versioning system... stable release is 2.x where
x >0 and x == even. Developmemt release is 2.x where x is odd.
Bill
> APACHE 2.x ROADMAP
> ==================
> Last modified at [$Date: 2002/10/01 19:13:06 $]
>
>
> 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.1-stable and Apache
> 2.2-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
> rational between
> the two versions and their behavior, going forward.
>
>
> STABLE RELEASES, 2.{odd}.{revision}
> ------------------------------------
> All even numbered releases will be considered stable revisions.
> That means;
>
> * 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.
>
> * 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.
>
> * 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.
>
> * 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.
>
>
> 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.
>
> 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.
>
>
> BINARY PACKAGES
> ---------------
> All emphasis will be focused on providing binary packages of
> stable release
> versions. While they are a volunteer effort, and the project makes them
> available only as a convenience and not on demand, the project will frown
> on contributors providing development release binary packages when there
> are no available binary packages available for the current stable release
> for the platform in question.
>
>