Need to point out that backwards compatibility is not as simple as simply
requiring that client and server are not too outdated.
As shown in issue 1160, you can be running recent client and servers (I
upgrade around 1 week after each 0.x release), and still hit some backward
compatibility bugs (in this case, repository started around 0.17 times had
a structure not compatible with current server code).
So .. just to say that requiring recent revisions is good, but that won't
be the magical answer ..
TTimo
On Wed, 12 Mar 2003 18:44:14 +0100
"Sander Striker" <striker@apache.org> wrote:
> > From: sussman@collab.net [mailto:sussman@collab.net]
> > Sent: Wednesday, March 12, 2003 8:38 PM
>
> > So let's come up with a written policy and stick to it. Then, when we
> > *do* break compatibility, and someone complains, we can point to the
> > writing. :-)
>
> My vote on the "courtesy upgrade time": 1 release. IOW, keep it backward
> compatible in the release the feature is introduced and drop the backward
> compat in the release that follows. I'm thinking minor releases here, not
> patch releases (and only for as long as major == 0, but we all agree on
> that).
>
> Sander
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
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:57:10 2003