Re: A suggested ROADMAP for working 2.1/2.2 forward?
Bojan Smojver wrote: Quoting Glenn <[EMAIL PROTECTED]>: -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?
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?
>
> >
> >
> > 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?
"William A. Rowe, Jr." <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: A suggested ROADMAP for working 2.1/2.2 forward?
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 r
Re: A suggested ROADMAP for working 2.1/2.2 forward?
At 12:03 PM 10/17/2002, Jeff Trawick wrote: >"William A. Rowe, Jr." <[EMAIL PROTECTED]> 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?
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?
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?
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?
"William A. Rowe, Jr." <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: A suggested ROADMAP for working 2.1/2.2 forward?
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?
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 <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: A suggested ROADMAP for working 2.1/2.2 forward?
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 <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: A suggested ROADMAP for working 2.1/2.2 forward?
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.
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 res
Re: A suggested ROADMAP for working 2.1/2.2 forward?
Quoting Bojan Smojver <[EMAIL PROTECTED]>: > 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?
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/ [EMAIL PROTECTED]
Engineer [EMAIL PROTECTED] Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101
--
Re: A suggested ROADMAP for working 2.1/2.2 forward?
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. +1to 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?
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 fe
RE: A suggested ROADMAP for working 2.1/2.2 forward?
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?
Quoting Glenn <[EMAIL PROTECTED]>: > -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!
