httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Wilde <twi...@dyndns.org>
Subject Branch Philosophy
Date Sun, 13 Oct 2002 03:41:01 GMT
I'll preface this by saying I'm not much of a developer myself, but I use
a number of major open source software packages, and follow their
development models pretty closely.

I don't understand all this fighting about branching and development.  I
don't understand why Apache 2.0 has been released, and recommended for
production use, if, as many seem to be saying, it isn't
"feature-complete".  Every other project I've ever seen doesn't do active
development on a released branch.  That's just NOT how to do things.  Yet
Apache 2.0's API is changing, it seems on a daily basis.  If this is
release software, why are you changing the API?

Examples:

mySQL - 3.23.xx is released.  Bug-fixes only.  4.0 is now in beta -
feature freeze, bug fixing for release.  4.1 is alpha, 5.0 is pre-alpha.
Those are where development is going on, use at your own risk,
back-porting major bug/security fixes to the released/stabilizing
branches.

FreeBSD - 4.7 is the current release.  Minor development occurs on the
-STABLE branch, which will lead to the release of 4.8, 4.9, etc, with a
-CURRENT branch for bleeding edge, which will become 5.0.  When 5.0 is
released, -CURRENT (which may then become -STABLE, with -CURRENT being
6.0) will be developed for 5.1, 5.2, etc.  FreeBSD "releases" never change
after they're released - point releases are made if absolutely necessary
(4.6.1 and 4.6.2, for example) and a security-patches-only CVS tag is
available for each release.

Perl - Releases are made on even numbers (5.6, 5.8) with development
happening in the next odd number (currently 5.9) which will be released as
5.10.  Changes within branches (5.6.1, 5.8.1, if/when they're made) are
for vital fixes only, and extensively tested in previous versions before
being released.

All of these projects have their own problems.  But at least their users
can know that "FreeBSD 4.7" or "Perl 5.6" is going to be the same piece of
software between 4.7.0 and 4.7.1 or 5.6.0 and 5.6.1, with only minor
changes.  That's not so with Apache 2.0.

I don't see what's so hard here.  Maybe 2.0 isn't "feature-complete" yet.
But I think it's time to give up on 2.0 and start doing things right.
Start developing full-time on 2.1.  Make it available as development
software, clearly marked as such.  Get it feature-complete.  Set goals.
Then, when the time is right, release it as 2.2.  While you're going,
backport bug fixes to 2.0 if they become necessary.  But don't make API
changes.  Don't change the heart of the software.  Heck, you shouldn't
even be making MAJOR API changes in 2.1 - PHP and Linux have both made
that mistake at different times, and many people would never touch them
again because of it.

Apache is a de-facto standard.  Don't wreck it by going around making
changes willy-nilly mid-stream and alienating your users.  Pick a
development model that doesn't have people running software that doesn't
even have functional helper applications as if it's release quality.  I'm
sorry, but a broken htpasswd binary is NOT acceptable in a GA release.  If
I'd read this list before I switched to Apache 2.0, I never would have
made the change.

I don't want to start a flamewar, and I know the first cry is going to be
"then why don't /you/ coordinate it?!"  Take my advice, or leave it.  I
don't have the time to coordinate a major software project, nor do I think
I'm capable of doing it right - certainly I couldn't do it "perfectly",
nor do I think anyone could.  I just think it can be done better than the
way it's being done here.

That's my several dollars of opinion.  Take or leave it, it's up to all of
you.  I just use the software :)  And I know there are a lot of people out
there who feel the same way I do.

Tim Wilde

-- 
Tim Wilde
twilde@dyndns.org
Systems Administrator
Dynamic DNS Network Services
http://www.dyndns.org/


Mime
View raw message