On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jcorvel_at_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
Received on 2012-07-11 19:26:08 CEST