Hi guys!

"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Hi Guys,
> 
> Just out of curiosity: Why is it necessary to go to the length that you are
> proposing with respect to the compatibility levels? It seems to me that a
> maintainer might be hard pressed to distinguish between CC 1 and 2 (I
> couldn't possibly imagine that absolutely no app would ever be able to use a
> changed package; so I'd probably always opt on the side of 2) as well as 3

Well, an example of CC1 would be if you have changed the core (=that all
clients must use) API so that clients *must* changed. In short - this
level means "It doesn't work, trust me, and the only reason you would
like to try is if you want to fix your client!".

CC2 on the other hand also has changes in the API, but depending on what
parts of the API that the clients use, they may be lucky and *may* work.
So this one means "It has a chance of working, but you will just have to
try it."

So the distinction here is important for the user - CC1 doesn't invite
you to "test and see if it works". It only invites developers to fix it.
The chance that it would work is immensely slim and is based on that the
maintainer simply is wrong and it should have been marked CC2. :)

CC2 on the other hand is the highest level of "incompatibility" and the
maintainer wants to tell you that the chances of success with an old
client are slim, but who knows - people win the lottery sometimes - it
still *is* possible. :)

Btw, my take on these levels (and currently in effect on SM) are here:

	http://map1.squeakfoundation.org/sm/category/cb51b604-bb97-415d-a040-f2
31ecdd5bc7

Unfortunately my level list is reversed - but you guys are smart. :)

> and 4 (how exactly do we define "not changed any old code"?)

To me CC3 means that the maintainer thinks it should be compatible, but
he has made changes.
CC4 tries to distinguish the fact that only extensions have been made.
Hmmm, I am also unsure here - but mostly because I may want a slightly
another way to distinguish:

In my categorization I used a variant - I wanted to separate the "only
bug fixes" from "changes yes, but not expected changes in external
behavior". If you fix bugs, you *do* change the external behavior - but
it can be considered to be changes of the "friendliest kind" hopefully
for the better! :) That seems to me to be the highest compatibility,
given that the API still *has* changed (=it behaves differently).

If you do *not* change external behavior, you may still have made a lot
of internal changes - refactorings, new algorithms etc. So LOTS has
changed, risks are high, but the external API is still not modified -
the external contract is intended to be the same. So that seems to be
the highest level of changes given that the external behavior is still
the same.

Obviously there are different ways to do this. The most important aspect
is of course that we - the maintainers - understand the model *and* that
the users (well, mostly that's we too) do too. :)

> or 5 and 6. It

Well, level 6 seems a pity to not distinguish. 6 means no *code*
changes, and could actually be machine verifiable. My proposed level 5
was "no changes to existing code, only additions". Because I considered
that to be the changes that would have the least probability of breaking
things.

> seems to me that we might be able to simplify this by saying we have three
> major compatibility levels:
> * interface/semantics unchanged (known to be compatible) (5 and 6)

6 must be compatible, otherwise the maintainer is either lying :) or...
well. In theory clients could depend on non-code elements of the code -
but *that* would be like cheating. :) Hehe, I just remember that
HttpView actually uses the method categories at one place - ok, sure,
but still... :)

> * interface/semantics (expected to be) compatible (3 and 4)

I think a distinction showing me *something* about the likelihood of
success would be nice.

> * interface/semantics (expected to be) incompatible (1 and 2)

Well, I still think that "expected to be incompatible" is different from
"it is incompatible, trust me, it doesn't work - no, listen, I am
telling ya, it *can't* work!" :).

> With possibly being able to further distinguish (if that is needed). At
> least for me, describing the compatibility level by using the above three
> levels would be much simpler than the six levels proposed and (judging from
> practice) these are precisely the levels that I typically care about as a
> client.

Well, we may never totally "agree" on this, :) but I am being "lenient"
in this because in my model these levels are meant as guidelines for the
user - they should give him guidance on the chances of things breaking
or not. So it is not the end of the world for me if it doesn't come out
exactly the way I would have liked it to. :)

Let us see where Stephan takes this, I am confident he will take the
feedback on this thread and remold it into something we all can agree
on. And then we will just see how it plays out.

> Cheers,
>   - Andreas

regards, Göran