I'll let you go ponder, but I guess I don't fully understand. It is a
Bad Thing at any time to break client/server compatibility. Hopefully
we never have to do it. I guess my only point, and I think the point of
this Wiki, is that *when* we have to do it, we have to do it at a major
release boundary, and we will document clearly that there is an
incompatibility.
If we can make a change such that it only breaks compatibility with
major release - 2 (e.g. the change in 12.0 works with 11.x clients but
not with 10.x clients), that's great. We can even agree to make this a
policy. But to me that doesn't meant we can make the change at a minor
release boundary.
David
Kathey Marsden wrote:
David W. Van Couvering wrote:
I also wanted to respond to the suggestion that compatibility be
guaranteed for a given time period, versus tying it to release levels.
If we don't *require* that major releases be incompatible, but simply
say this is the only time you *can* do it, then I don't see what the
issue is. We can do as many major releases as we want in five years.
If we want to also provide a guarantee that any feature will not be
broken for five years, that's OK, but I think it would be odd to break
compatibility in a minor release just because it's been five years...
Or am I not fully understanding your proposal, Kathey?
It is not a proposal, kind of more of a typical user requirement. I
need to think some more on how to that might be implemented from a
product perspective. Perhaps the guarantee of client/server
compatibility with the previous and next major release would be a
more realistic approach. Certainly the kind of jump suggested where
there is no compatibility between v10 and v11 clients and servers would
be a very hard move for users. Upgrade is another area I need to
understand better across major version boundaries. Anyway, all just
random thoughts at this point. As I said I need to think more. I will
study your proposal and all this just as soon as I can and get back.
Kathey
