apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: apr versioning (was: cvs commit: ...)
Date Sun, 11 Nov 2001 23:54:37 GMT
On Sunday 11 November 2001 02:07 pm, Greg Stein wrote:
> On Sun, Nov 11, 2001 at 09:14:42AM -0800, Ryan Bloom wrote:
> > On Saturday 10 November 2001 11:23 pm, gstein@apache.org wrote:
> > >     ### we have not defined source/binary compatibility guidelines yet
> > > and ### how those map against these (release) version numbers. a
> > > strawman ### would be the following text:
> >
> > We should have this discussion now.
> That is why the comment was there :-)

I know.  :-)

> Also, I'd like feedback on the overall approach. If people don't have any
> major issues with it, then I'll use the same thing in APRUTIL.

In general, I like the approach.  I am on the fence about the is_dev stuff,
but I need to think about it more.  I'm just not sure we need it, but then I
think about it, and I think it's a nice feature.  I can go either way on that I

> Also, if it seems fine, then I'll have configure.in extract the version
> number from the header and pass it to libtool (to create libapr.so.X.Y.Z).
> I just didn't want to do that work (a good bit of testing is involved)
> unless people are happy with the overall approach.

++1.   :-)

> > >     APR is binary-compatible (an app compiled against one version does
> > > not need to be recompiled to work against another version) for the same
> > > MAJOR and MINOR versions.
> > >
> > >     APR is source-compatible (an app needs to be recompiled, but will
> > > work the same) for the same MAJOR version.
> > >
> > >     If the MAJOR version changes, then an application may need source
> > > changes.
> >
> > This is a library, backwards compatibility is a must.
> Before using the term "backward compatible", we should define what we mean.
> There are a couple different interpretations. (which is why I avoided it
> above, altho I removed too much of my forward/backward discussion; the
> comments need more tweaking)
> APR needs to be "forward compatible". An app built against 1.0.0 should
> work against later/future/forward releases of APR.
> APR does not need to be "backward compatible". An app built against 1.3.2
> does not have to work against previous releases of APR.
> [ i.e. APR is moving backwards/forwards; what happens to the app? ]

Coolness.  You have given this an awesome amount of thought, and I agree with
all of the definitions above.  I will strive to use them in the future.

> The next question is what kinds of changes the app may need to make when
> the version numbers change. Consider an app that was coded and compiled
> against 1.0.0. When a later version comes out, what happens?
> 1.0.0 -> 1.0.1 : no recompile; relink against new .a; new .so just works
> 1.0.0 -> 1.1.x : recompile. relink against .a and .so.
> 1.0.0 -> 2.x.y : source changes
> Now consider an app built against <some> release; what is possible?
> 1.0.1 -> 1.0.0 : no recompile; relink against old .a; old .so just works
> 1.1.x -> 1.0.0 : won't work; the app may have used new 1.1 APIs
> 2.x.y -> 1.0.0 : won't work; needs source changes
> > If we break backwards
> > compat after we release, we will have broken a lot of users.  -0.9 for
> > ever allowing backwards compat to be broken.
> I agree, if your meaning of "backwards compat" actually matches my "forward
> compat" definition above.

It does.  :-)  Wow Greg, what happened.  All we used to do was fight.  Now
we agree more often than not.  :-)

I don't believe that backwards compat is necessary at all, given the definitions

> > If the MAJOR number is increasing,
> > then a program should never need to be re-compiled, let alone source
> > changes.
> Going from APR 1.0 to APR 2.0 could definitely require source changes (and
> those required changes is most likely *why* MAJOR was bumped). Are you
> saying that an app built for 1.0.0 will never, ever need source changes?
> That just isn't right, and it isn't feasible. Did I misunderstand what you
> meant?

I agree in part only.  The only reason that an app would need source changes are if
APIs have been removed or the prototype was changed.  We shouldn't do that.
If we want to remove an API, then we should mark it deprecated for a release,
and then remove it in the next major bump.  That would basically state that 
an app would have until the next release to modify their code, or they will
be stuck on an older version of APR.  

If we are modifying an API, then we should continue to support the old API,
although it should be marked as deprecated.

Each release should come with a list of deprecated APIs if any exist, so that
our users can easily determine the problem functions.

What I don't want to see, is I wrote a program against APR 1.0.99, and then
2.0 is released.  My program all of a sudden does not compile anymore,
because an API was removed without warning.  I would rather see the API
moved to a new file, deprecated2.0.c, and in APR 3.0, that file should be
removed, removing the deprecated functions.

This provides a lot of warning before a function disappears.  Does that make

Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message