Re: Final counting approaches...

["William A. Rowe, Jr." <wr...@apache.org>]

[Context: we are discussing the creation of an APACHE_2_0_RELEASE
branch and forking off API-breaking changes to a 2.1-dev branch.  Greg's
question goes to APR, which is why it's cc'ed.  Please keep this cross
posted thread about how Apache and APR versioning interact on topic :-]

At 11:01 AM 11/8/2002, Greg Ames wrote:
> What about apr?  the same?

No.

APR isn't Apache, nor should it be.

I see the following happening to APR;

* Tag APACHE_2_0_44 just as we've done for every release *thus far*.

* Fork APACHE_2_0_BRANCH only within the httpd-2.0.

Now; once the APR project reaches 1.0, we can consider releasing 2.2.
APR will be following it's own well-defined versioning contract with
developers.  Any Apache 2.2+ will build under any APR 1.x until *we*
decide to break binary compatibility with APR 1.n-1 or prior (when we
choose to use some new API introduced in 1.n.)  If that breaks our
long-term compatibility goals, we can always kick off 2.4, requiring
the given APR 1.n.  This probably won't be required since the Apache
project hasn't put forward any forward compatibility guidelines.

Our APACHE_2_0_BRANCH may always use an APR 0.9.x.  If a security
patch requires an update to that 'final release' of APR 0.9.x, we can all
decide what to do about it then (perhaps create a maintenance fork from
APR 0.9.x.)

And the final option once APR is at 1.0 is to release an APR 1.0 release
of Apache 2.0.x.  We would break our own versioning rules for the 2.0.x
series, but folks haven't come to expect much stability out of 2.0 in the
first place.

If the APR project didn't believe it was close-ish to the 1.0 release, the
entire Apache versioning proposal wouldn't even be on the table :-)

Bill 

RE: Final counting approaches...

[Bill Stoddard <bi...@wstoddard.com>]

> And the final option once APR is at 1.0 is to release an APR 1.0 release
> of Apache 2.0.x.  We would break our own versioning rules for the 2.0.x
> series, but folks haven't come to expect much stability out of 2.0 in the
> first place.

I think re-releasing 2.0.x against APR 1.0 would be a mistake (I am assumiming
of course that APR 1.0 would not be compatable with APR 0.9.x).  We are about to
send a signal to our users that 2.0.x is now 'stable'.  If we break it, that
just flushes our efforts down the tubes, don't you think?  Our message to the
user community should be easy to understand, direct and should not contain more
than ONE caveat.  I think our message should state that every release in the 2.0
series from 2.0.42 on out WILL be binary compatable with the previous releases.
The only caveat is if we discover a serious security exposure that requires
breaking binary compatability. Introducing an APR 1.0 caveat would not be cool
IMHO.

Bill