httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: binary backwards compatability.
Date Mon, 03 Apr 2000 20:04:23 GMT

There is one thing that has been bothering me since I originally brought
this up, and I have been trying to figure out what it is.  Well, I finally
got it.  :-)

When this issue was first brought up Dean said:

"during a minor release cycle (x.y.n -> x.y.n+1) we will attempt at *all*
costs to maintain backwards binary compatibility

i'm all for it.  except i thought that was already the state of affairs."

This is all I have asked for.  During point releases, we shouldn't be
breaking binary compatibility.  If all we need to do to accomplish this is
to develop a policy that says:

"If you require a change that neccessitates a Major Module Number bump,
then that change should be brought up as a reason for a new major

This states that ANY changes that go into point releases are binary
backwards compatible, and that we are willing to make changes that affect
binary compatiblity, but those changes will be made (whenever possible) by
releasing a new major release.  This does mean that we will have more
major releases, which IMHO is not a bad thing.


On Mon, 3 Apr 2000, Randy Terbush wrote:

> > Trying to create a mechanism to allow modules to execute on future
> > versions is prone to error and will be amazingly prone to feature creep.
> > I've heard about stabilizing APIs, only adding new APIs, feature
> > capability sets and versioning, etc. Sheesh. With all that complexity,
> > we'll add more bugs than if we just made the vendor recompile their dang
> > code.
> >
> > Cheers,
> > -g
> Greg, I'm a bit surprised by this attitude. It is non-trivial to stay
> current with Apache minor releases. It is also quite silly to have to offer
> modules for 1.3.0-12 just to support a difference in MMN with no significant
> difference in the API. With more third-party module vendors offering their
> applications on Apache, we only increase public acceptance of this platform.
> That is a great thing for the project.

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message