Greg Stein wrote:
> It isn't "simply too great". It just isn't possible. If you compile
> against 1.1.x, then your application *requires* 1.1.x. There isn't
> anything that you can do unless you lift the hood and dig very very
> hard to ensure that your app can bind/work against 1.0.x.
>
> The simplest example is a #define constant changing from 1.0.x to
> 1.1.x. That changing value can then make a particular function
> alter its behavior. It would know whether a 1.0.x or a 1.1.x user is
> calling it. This kind of change in the constant is acceptable under
> the guidelines.
Um, the APR versioning text seems to explicitly disallow changes to
constants. It also says "Further, if an application is designed to
work with an earlier minor version, then we don't want to suddenly
change the requirements for that application. This means that the
headers cannot silently map an old function into a newer function, as
that would turn an application, say, based on 1.2 into an application
requiring the 1.4 or later release." And even more "It is possible to
design a set of headers where a macro will always refer to the
'latest' function available. Of course, if an application chooses to
use this macro, then the resulting compiled-binary will be dependent
upon whatever version it was compiled against. This strategy adds the
new functionality for applications, yet retains the necessary source
and binary compatibility for applications designed or built against
previous minor releases."
I don't know, maybe I am just reading the guidelines through my own
set of tinted glass, but I read the minor version constraints as such:
- Application coded originally against 1.0 headers is source and
binary compatible against later minor versions, but also that
application compiled against 1.1 headers is still binary compatible
with 1.0 libraries, if there are no library versioning issues on the
OS level.
- Application coded against 1.1 headers, but without using any 1.1
specific features, is still source and binary compatible against 1.0,
regardless whether it has been compiled against the 1.1 headers or
1.0 headers.
If this is *not* so, then obviously all that I have been talking here
is about princesses and toads.
> Something built against 1.0.x must continue to function with the
> 1.1.x libraries (and the guidelines are defined to enable this), but
> the reverse does not hold true. If you install a 1.1.x application,
> then the libraries must be upgraded to 1.1.x. The theory here is
> that an administrator can feel safe doing the upgrade because it
> will not break any existing 1.0.x applications.
The upgrade mentality is sound, yes. But I always saw that applying to
only applications that actually use the 1.1 specific features, and not
just being compiled or coded against 1.1.
>> Well, I still consider the approach here unconventional, but by no
>> means unsound. So as long as it is documented, it's all rose petals
>> and vanilla ice-cream.
>
> Unconventional? What aspect? I must have missed an earlier post of
> yours :-)
No, I don't think you have. I just haven't seen any project where
deprecated functions would have not disappeared in a following major
release, but instead become the supported functions again. Also, I
don't believe I have seen the something2 naming for new functions
anywhere. So I would not call those methods conventional. But that may
ofcourse be just me.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 18 14:16:43 2004