> On Sat, 2003-12-06 at 02:16, Justin Erenkrantz wrote:
>> As John pointed out, what would 'svn --version' say under this scheme?
>> Or,
>> would we only have x.y.z for stable releases?
>
> This question was answered by Kevin in
> <http://www.contactor.se/~dast/svn/archive-2003-12/0257.shtml>. "svn,
> version snapshot (r12860)"
I think that is a wrong way to go about it. How does a snapshot relate to
the latest released version? Remember that we're saying that 'svn
--version' on official releases don't have a revnum in their version
either.
I'd like to be able to correlate the version information by looking at the
output of version in the svn binary. Kevin's strategy doesn't allow for
that. Hence, we need some point of reference.
>> How about version compatibility and binary compatibility rules? They
>> have to
>> apply at all times once 1.0 hits.
>
> Those seem orthogonal.
I disagree. The ABI versioning rules we have in place are directly tied
into version numbers, so they aren't orthogonal. Enforcing ABI versioning
without the x.y.z format is going to be painful. If we follow the x.y.z
format for ABI versioning, most dynamic linkers will play nice.
> I don't think we should tie our shared library version to our package
> version. It's possible that we'll want to release svn 2.0 without
> making incompatible changes to the ABI (perhaps we added distributed
> operation, but managed to do so by only adding things in a compatible
> fashion to the schema, working copy, and network protocols). It's also
Then, I don't believe it would be called svn 2.0 if it has the same ABI as
1.0. Perhaps we add the additional constraint that changes to the SVN
repos backend can occur on minor version updates (i.e. 1.0->1.1).
(Ambivalent about that though.) But, I believe the primary focus of the
version numbers should be about third-parties integrating with Subversion,
and the secondary focus is on users understanding what it means.
Hence, I believe our version numbers should be extremely tied in with the
binary compatibility rules. When we make a change that fits under the
minor category, we bump to 1.2 (under odd/even rules); when we make a
change that bumps the major version of the shared library, we go to 2.0.
That tells third-parties when they need to release a new version.
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.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 7 03:41:52 2003