Re: Bump minimal APR version
From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Thu, 11 Mar 2010 10:18:50 -0600
On Mar 11, 2010, at 9:31 AM, Mark Phippard wrote:
> On Thu, Mar 11, 2010 at 10:25 AM, Hyrum K. Wright
I dunno. The *vast* majority of people get a prepackaged client. As Peter mentioned elsewhere, Debian has been shipping apr 1.2.x with Subversion for some time, and I suspect that a large number of other clients have already moved to apr 1.x. The *only* people an apr version bump affects are developers and people who build Subversion from source, who are vastly in the minority. (I'd be interested to know who in the dev community still uses apr 0.9.x, for instance.)
> Yet, we force ourselves to jump through hoops keeping our libsvn_wc
I *think* what you're saying is that our compatibility guidelines are a bit screwy. If that's your assertion, I tend to agree. :)
When we talk about backward compat, there are actually several dimensions we've lumped into one:
For a long time, we've tried very hard to keep *all* of these backward compatible, but experience has shown that most users only care about a subset of these dimensions (though that subset may differ between groups of users). As Subversion continues to evolve, we need to figure out which areas are important, and which we can drop if/when we go to 2.0.
For instance, I believe that we should maintain wire protocol compat ad infinitum, even through 2.0, simply because it allows people to continue deploy a heterogeneous client/server environment. We've already practically broken our wc metadata format, and we've occasionally extended the command line output when it's made sense. (I often wonder how people who scripted against 'svn up' dealt with the new conflict summary.)
Staying backward ABI compatible *forever* just isn't scalable. At some point, the costs outweigh the benefits , and I'm suggesting that maybe we should start thinking about what the costs are, and whether it makes sense to tell the 0.0001% of people who'd need to recompile to do so. (This is somewhat analogous to the decision to not upgrade pending logs in wc-ng.)
As Jeremy alluded to elsethread, we've continued to support platforms which aren't even supported by their respective vendors anymore. I reiterate my statement that if users want a new enough Subversion, they may need to upgrade other aspects of their systems as well. If done gracefully, the updating of compatibility can be done effectively.
(FWIW, I think doing a green-field implementation of wc-ng probably would have taken just as long. The incremental approach we've taken has yield a plethora of benefits, not the least of which has been the ability to continue to leverage the existing test suite. I personally see wc-ng as a stepping stone to 2.0, but that's a discussion for another day.)
I'll now pause, to let Greg flame me. :)
This is an archived mail posted to the Subversion Dev mailing list.