Timothee Besset <ttimo@idsoftware.com> writes:
> I suppose you could have a look at issue 1160 too
> http://subversion.tigris.org/issues/show_bug.cgi?id=1160
>
> Typically that's an issue related to repositories started around 0.17
> times, which nicely disappears if you do a dump reload with nowadays
> stuff.
>
> Personnaly, I am carefully keeping my client and servers at the last
> release, or the one right before. e.g. everything is 0.18 and will move to
> 0.19 within a few days.
>
> As a user and server admin, I don't mind if every now and then we decide
> to cut backward compatibility (for say anything < 0.18). Specially if that
> helps getting to that magical 1.0 faster :)
See, that's kinda my take, too.
We don't want every released tarball to break everyone's world -- no
amount of saying "Well, now, we promise we won't do this to you after
we hit 1.0" is going to make early adopters really trust us. I also
know that typically, the repository maintainers and the clients who
access those repositories don't want to have to coordinate on which
exact version of Subversion each will be using for his side of the
network. So, I do feel like some degree of compatibility work is
needed, and that in the future, this will only become more difficult.
But I also feel that the many-months time windows are slowing us down.
Perhaps the policy before 1.0 should be:
Release clients and servers whose minor numbers are 0 or 1 apart
will work with each other.
Yes, that means that server maintainers and clients will need to
upgrade pretty much with every new tarball that is released, but at
least they have a couple of weeks of buffer time in which to do that
(basically, they have until the next minor release comes out). Once
we hit 1.0, the game is much tighter for developers, of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 12 18:00:36 2003