Concerns about suggested version strategy

[Justin Erenkrantz <je...@apache.org>]

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

Re: Concerns about suggested version strategy

[Jim Winstead <ji...@apache.org>]

On Fri, Oct 18, 2002 at 10:22:55AM -0700, Justin Erenkrantz wrote:
> >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?)

i think what is currently being discussed with regard to the next stable
linux release shows how you handle the version-before-major-jump
numbering. the development tree is 2.5 -- the next stable tree could be
either 2.6 or 3.0, depending on how major the differences are relative
to 2.4.

jumping the major number of the development branch presumes you know
beforehand what major changes are going to go into that development
branch. what happens when someone commits a change to 2.x that people
then decide warrants making the next stable release a 3.x?

jim

Re: Concerns about suggested version strategy

[Ask Bjoern Hansen <as...@develooper.com>]

On Fri, 18 Oct 2002, Justin Erenkrantz wrote:

> > All even numbered releases will be considered stable revisions.
>
[...]
> 1.99 series to do development for 2.0.  (What is Perl doing for 6.0
> development?)

To answer your question first: For mod_perl we are using
1.99_[patchlevel] for the development releases leading to mod_perl
2.x.  I don't think there are any plans for using the odd/even
scheme for mod_perl.


With Perl it's a bit different;

Perl6 is an entire rewrite, so it doesn't really count.

We only started using the odd numbers for development releases with
perl 5.6; previously to that the versioning scheme was
[major]_[minor]_[patch_level].  The last version of perl 5.5.x was
called 5.005_03.

Back then we used patch level 50+ for development releases; so perl
5.005_50 was the first development release leading to 5.6.0 (which
would have been 5.006 in the old scheme.

Of course major has not changed for 5 years (this Thursday IIRC!),
so it got a bit silly; hence the change to using the
major.minor.patch which really should be treated more like
5.major.minor.  :-)

> 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 don't think it makes sense at all.  Lots of software is unstable
in the .0 release, but I never heard of it being that way
intentionally.  And we try to be better than the rest, no?  :-)

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

+1 to that.

(of course with mod_perl we have a compatibility API, so most old
modules will actually work :-) )

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

Yes!  Otherwise it doesn't make any sense.


  - ask (bikeshedding away)

-- 
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();