[trimming Cc, clearly you're all reading dev]
[David Glasser]
> I was always under the impression that the deps tarball was a way of
> not scaring off people from installing Subversion back when it was a
> brand new system nobody had ever heard of with a surprising number of
> dependencies. Now that Subversion is dominant enough that no
> self-respecting system makes it hard to get svn up and running (and
> even major consumer operating systems ship with svn by default), the
> deps tarball seems like a nice gesture, but hardly a source of
> compatibility worries.
I don't know if users would read your statements about libsvn binary
compatibility until 2.0 and assume that it doesn't apply if you use the
deps tarball. (The INSTALL file pretty much says otherwise.) Myself,
I would have assumed that the deps tarball, which is signed and md5'd
and everything, was an implicit part of the distribution and the QA
process (including compatibility testing).
Maybe the solution here is to make it clear that using the deps tarball
voids your binary compatibility warranty, that warranty only being
honored if you stick to the same external libraries for each new
Subversion build. (In practice, I believe this only actually matters
for apr (and apr-util and serf, which use apr). The other external
ABIs are shielded from consumers of your API.)
Also, as Kamesh noted, the INSTALL file needs to be updated to remove
the bit about how you're shipping apr 0.9 out of concern for binary
compatibility.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-08 16:57:07 CEST