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
