Concerns about suggested version strategy

[Justin Erenkrantz]

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
[EMAIL PROTECTED] for the stable tree, or to the
[EMAIL PROTECTED] 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