On Sat, Sep 25, 2010 at 02:43:37PM +0200, Daniel Shahaf wrote:
> Ramkumar Ramachandra wrote on Sat, Sep 25, 2010 at 11:59:49 +0530:
> > Daniel Shahaf writes:
> > > Would svnrdump benefit if, once 1.7.x branched and RC's start being
> > > rolled, it were subjected to a more relaxed backporting policy?
> > >
> > > If so, we might consider moving it to tools/ for 1.7.x, with intent to
> > > move it back to subversion/svnrdump/ for 1.8.x (as soon as 1.7.x is
> > > branched from trunk).
> >
> > Hm? I don't understand how it'll help backporting. I already maintain
> > an out-of-tree build that successfully compiles against 1.6 [1]. It'll
> > be fairly trivial to write an svn18_compat module.
> >
>
> We'll be able to follow a more relaxed "Is this change backportable"
> policy.
I don't really mind where svnrdump lives.
The community is committed to supporting both the tools/ and subversion/
directories.
If backwards-compat rules automatically apply to everything below subversion/
(they do?), and that people feel that svnrdump may still change in
backwards-incompatible ways, we might as well decide to make the
subversion/svnrdump directory exempt from such guarantees during the
1.7 release. It is a simple technical decision: Do we think that
the current feature set is worth supporting under our backwards-compat
rules? I do.
> > Hyrum K. Wright writes:
> > > I would add the further thought that as this is a "tool" rather than a
> > > first-class component, I think we can play a little bit looser with
> > > the rules.
> >
> > For what it's worth, I have a different opinion on this issue.
It really doesn't matter. It's just the name of a directory and a set
of promises we give to our users about backwards-compat.
There's no need for hard feelings.
Stefan
Received on 2010-09-27 14:53:03 CEST