Code compatibility or clarity and consistency?

I am writing a new version of a dll I have made generally available (the EventVB.dll) and in doing this I am altering the object model (class names and enumerated type names mainly).

However this extra clarity and consistency comes at a cost - the dll will no longer be backwardly code compatible if the existing code uses the changed functions (mainly in the area of windows hooks).

The question is which should I pay most attention to - providing a consistent object model or providing code compatibility?
(I realise I should have been consistent from the start, but hindsight s always 20:20)

I'd appreciate your thoughts,
Thanks in advance,
Duncan

It depends how many clients use this DLL. Obviously, if they want to use the new functionalities, they will need to adapt their code. There is no simple rule to decide what to do. One thing you could have done is provide the same interface but declare this interface as deprecated, but then it might be difficult to sustain two versions of the same thing.

If I code for myself or my code is not provided as a SDK, I would think clarity is the way to go. If I already put my feet forward and the code has been downloaded by people, well, your guess is as good as I am, but usually, the situation will dictate what you should do. If a client wants compatibility, give him compatibility. Period.

Good luck

How about letting the size of the library grow a bit, and add another *copy* of the class with the new Name and arguments, etc. (Although there are less expensive *interfacing* options, if you plan to change ONLY the names) ?

Then, as Martin said, announce the older classes as deprecated. People will slowly shift over to the new classes. Add new functionality only to the new classes. So developers wanting to utilize it will use the new Classes by itself.

Later..after 2-3 versions, you can choose to remove the old code.