[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Compatibility, and Frustration.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-03-12 20:37:51 CET

cmpilato@collab.net writes:

> I want to see a policy, noted in the HACKING file, that describes the
> minimum length of time code needs to dance around compatibility
> problems. If it's a month, fine. If it's three months, fine. If
> it's "pre-1.0 we don't give a rip", fine. But it needs to be
> something, and it needs to be written down and adhered to.

Thanks for sending this mail, Mike. We're definitely seeing eye to
eye here.

For a 1.0 project, forward/backward compatibility is very important.
That's what major and minor version numbers, ABI and API policies are
all about.

But because we're still a pre-1.0 project, the issue of compatibility
is really an issue of *courtesy*: how nice do we want to be to current
users?

In my mind, it's a sliding scale. At one extreme, it's "screw all the
users; break compatibility whenever we want; they should be
upgrading to HEAD every day anyway." At the other extreme, it's
"ohmigosh, somebody might still have a repository from two years ago!
we can't abandon that person!"

The sane policy lies somewhere in between. What Mike is (justifiably)
upset about is that we seem to have no consistent policy at all. I've
watched the same discussion happen over and over (in the Chicago
office, in particular) about "how much courtesy upgrade time should we
allow for feature X?" And everytime we have such a discussion, the
mood of the day seems to determine the answer. Sometimes the answer
has been 3 months. Sometimes 6 months or 1 month. Or in the case of
0.19, I guiltily admit that Karl and I agreed, "heck, let's make the
release compatible with older clients, but leave the incompatibility in
/trunk". Totally inconsistent.

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. :-)

---------------------------------------------------------------------
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:39:19 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.