httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Concerns about suggested version strategy
Date Fri, 18 Oct 2002 17:22:55 GMT
Okay, so I finally had a few minutes to spare and read through the 
ROADMAP.  (Again, I'd like to see this separated from the to-do list!)

Here are my concerns (ROADMAP quotes are prefixed by >):

> All even numbered releases will be considered stable revisions.

What do we do for bumping of major numbers?  Say we want Apache 3.0. 
How do we do the -development release for that?  Linux has done the 
1.99 series to do development for 2.0.  (What is Perl doing for 6.0 
development?)

Regardless of what Linux or Perl do, I think there is a real problem 
with having stable be even and odd be development.  (We could treat 
zero as odd, but then we have 0, 1 as both odd - ick.  So, zero is 
traditionally even in our context.)  So, I'd much prefer that we 
stick with OtherBill's initial suggestion - it makes it easier for us 
to do development on new major numbers.  The first odd release (0 != 
odd) is a stable release.  It just makes more sense.

I'd also like to quantify what a major number bump means.  My guess 
would be, "Brand new architecture in httpd X.  You have no hope of 
porting your X-1 modules.  Don't even try."

> 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 stable release cycle, 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.

Does this mean that every change in -development must be reviewed 
before it can be promoted into the next -stable release?  For 
example, are we talking about a change made in 2.3-development going 
into 2.4-stable?  I have a sneaking suspicion you might mean 
2.3-development changes going back into 2.2-stable.  The next 
paragraph makes the intention of this paragraph slightly unclear.

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

I'm confused about the intention of this paragraph when considered 
with the previous one.  My intention would be that we would take a 
vote on the current status of the tree as a whole.  If we all agree 
that it is stable, then someone takes the code and merges it into 
stable.  If there is a brand-new change that we don't want to 
introduce, fine, we can skip that change.

Let's say someone did an auth rewrite and it lived for a long time in 
-development.  I don't think there are any grounds for keeping it out 
of -stable.  Everything in -development must be there with the 
knowledge that it should be included in the next -stable release.  If 
that's not the case, then we shouldn't have it in the tree at all. 
Features and fixes and whatever shouldn't be relegated to only 
development tree.

This sort of makes me want to say that vetos do not apply (majority 
only) to whether a change is propogated from -development to -stable. 
A veto could be made to punt it out of the tree entirely.  But, once 
we have it in the tree, it's there.  Of course, vetos must be backed 
by a technical reason.

A side note: backporting from -development to a previous -stable 
should be subject to a veto - that ensures the integrity of the 
stable tree.

> In order to avoid 'skipped' release numbers, the Release Manager
> will generally roll a release candidate (APACHE_#_#_#_RC#) tag.
> This is true of both the stable as well as the development tree.
> Release Candidate tarballs will be announced to the
> stable-testers@httpd.apache.org for the stable tree, or to the
> current-testers@httpd.apache.org list for the development tree.

I have to say that I don't want to see releases for -development 
trees become a PITA.  So, we could do the long drawn out process for 
-stable releases, but I'd much prefer that we keep the 'versions are 
cheap' methodology to the -development tree (incl. skipped releases). 
I think that model works really well for development.  And, our 
current classification system (alpha, beta, GA) would apply to a 
-development tree only.  Only GA quality releases can be produced in 
-stable.  Even then, we often have skipped version numbers (see 
Apache 1.3).

My only other concern is that -stable should be RTC.  CTRTC (-dev 
before -stable) has the same effect.  But, I think people shouldn't 
be allowed to commit to -stable without three +1s.

I also have concerns about implementation of this versioning policy, 
but those concerns can wait until we have the policy set.  -- justin

Mime
View raw message