On Sat, 2003-12-06 at 21:41, Justin Erenkrantz wrote:
> I think that is a wrong way to go about it. How does a snapshot relate to
> the latest released version?
I don't think it's terribly important that they be easily related. If
we branch for 1.1, then put out a trunk snapshot, then put out the 1.1.0
release, then the trunk snapshot may have features not present in 1.1.0,
but may not have bugfixes present in 1.1.0. Should it look newer or
older?
> Then, I don't believe it would be called svn 2.0 if it has the same ABI as
> 1.0.
So, let's say that something forces us to change the libsvn_client major
version number from 1 to 2. Are you saying we should bump the major
version on every other library we have, just to stay in sync? That
seems awfully expensive.
> I believe that not having an ABI versioning system or not making the
> principal version be the ABI version is going to engage the wrath from
> third-parties that are aiming at moving targets. We got flamed in
> httpd-land for breaking things without an ABI contract - we learned and
> now have explicit rules - only now are vendors starting to support 2.0
> correctly. I believe Subversion should learn from those experiences.
Nobody's saying we shouldn't have ABI versioning.
> Also, splitting ABI versions from the 'real' version is going to be a path
> fraught with extreme confusion. 'SVN 1.5 with ABI 1.2.3' Ick. -- justin
For fun, try running this script on any RPM-based system:
#!/bin/sh
cd /usr/lib
for lib in *.so.*.*.*; do
libname=`expr "$lib" : '\(.*\)\.so.*'`
libver=`expr "$lib" : '.*\.so\.\(.*\)'`
pkg=`rpm -qf $lib`
pkgname=`expr "$pkg" : '\(.*\)-[^-]*-.*'`
pkgver=`expr "$pkg" : '.*-\([^-]*\)-.*'`
printf "%-40s %-20s %s\n" "$libname ($pkgname)" "$libver" "$pkgver"
done
Then run the output through
awk '{print $3 == $4}' | sort | uniq -c
On my machine I get 27 matches and 193 mismatches. (A few of the
mismatches are actually loose matches, but not many.) By and large,
shared library versions do not match package versions. If this path is
fraught with extreme confusion, then we are already quite confused.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 7 04:23:53 2003