I'm not happy with making it easier for downstream users to build
incompatible libraries. The versioning guidelines that we set up at
the start create a very strict, *and* a very high expectation of
compatability. I don't want to see that trust lost, or a set of
caveats introduced, through a way to toss symbols from our libraries.
We can tell people with a perfectly straight and honest face, "Upgrade
to the latest rev. It is Totally Compatible." Any questioning around
that statement is damaging, I believe.
Cheers,
-g
On Sep 29, 2008, at 22:45, "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu
> wrote:
> Over the past few days, I've been working on compile Subversion
> without any of
> out deprecated symbols. This of course creates libraries which
> don't abide by
> our API compatibility guidelines, but it also creates smaller
> libraries which
> don't have extra cruft unneeded by some of our consumers. For
> example, for a
> statically-linked, stripped copy of the command line client:
>
> 1705036 bytes with the deprecated symbols in
> 1659976 bytes without the deprecated symbols
>
> This may not seem like much, but I don't think some of our API
> consumers would
> scoff at shipping a 45kB smaller tarball.
>
> To enable this, I'd like to make a new configure-time option. To do
> so, I
> propose the following process:
> 1) Move all the deprecated symbols and definitions to a common
> location in each
> file. We could also move all the deprecated functions in a
> library to a
> common file, as has been previously suggested.
> 2) Introduce SVN_EXCLUDE_DEPRECATED, dependent upon some configure-
> time magic.
> 3) Wrap the sections created in (1) with SVN_EXCLUDE_DEPRECATED.
>
> The one catch here is that the tests will need to be updated to
> remove use of
> deprecated APIs. (I've already done this as part of my initial
> analysis.)
> Although I was initially opposed to such an idea, I'm starting to
> come around.
> Do other people have strong feelings about this?
>
> -Hyrum
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-30 01:13:51 CEST