On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote: > On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >> ... >> For instance, we could simply package two set of binaries/libraries in >> one package (the 1.8.0 version together with 1.7.x (taken from the >> corresponding tag)), and implement a main wrapper that delegates >> everything to the appropriate version. The 1.8.0 code doesn't need to >> care about the 1.7-compat stuff, we just have a dispatcher and package >> the old code together with it. I'm just fantasizing of course, for >> illustrative purposes only :-). But ... it depends. Anyone have a >> creative idea how this could technically be done and what the pros and >> cons would be? > > Or some third-party could just do this, and we wouldn't have to mess > with it at all. If there is a demand, somebody will step up and do > it, but I don't think we (as the Apache Subversion project) should too > much about it.
That's true, but one of the problems I'm trying to solve here is users having different clients on their system, each with their own release cycle. Maybe one of those offers this back-compat feature (e.g. currently the one that uses svnkit under the hood), but not the other two. That problem can only be solved, I think, if the core project makes this a built-in supported feature. -- Johan