httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Padwa, Daniel" <daniel.pa...@gs.com>
Subject RE: stable 2.0 trees
Date Tue, 15 Oct 2002 14:30:23 GMT
> At the risk of racing too far ahead in this discussion, here is my
suggestion...
> 2.0.43 becomes 2.1 and the MMN major does not change for subsequent 2.1
series
> releases (except for a compelling reason, eg a security fix -requires- a
bump).  Why
> 2.1?  No technical reason; purely a PR tactic to telegraph to the user
community we
> are putting a lot of focus on maintaining binary backward compatability
and to get
> rid of the *.0.* in the version number (yea, to appease the folks who are
allergic to
> 0's in version numbers).

> New ROADMAP development is started in 3.0.

<thunderous applause/>

I think Bill hit an important point here.....version numbers signal a lot to
the user community about the compatability of the code, and the pain in
migrating to various versions.   To a developer, the name of 2.0.43++ isn't
so imporant - call it 2.0.44, call it 2.1.0, call it 17.9 - it's the same
code.   To a user, the migration from 2.0.43 to 2.0.44 should be easy.
>From 2.0.43 to 2.1 can be a little harder.

It's much easier for end-users to understand releases if major functionality
and/or API changes are coupled with minor version number bumps (instead of
subversion bumps).  From that perspective, changing the auth semantics
(which have been pretty stable since at least early 1.3) 2.0.44 seems almost
sneaky compared to changing them in 2.1.0.

If minor version numbers are bumping weekly, that's not so good.   If they
are bumping quarterly or so as APIs change, that may well be healthier than
carrying the 2.0 series on until the next major code reorganization.

Version numbers are a marketing issue at least as much as a technology issue
- here's an easy chance to give non-developers more insight into what is
going on.

Mime
View raw message