So the collections way to handle this issue if to move all classes to a new
subpackage and leave the old ones where they've been before. To be honest: Is this not very close to my proposal?
Certainly, there is some similarity. Were I to change the semantics of a class/method (deliberately), to such a degree that it was backwards incompatible, I would have to create a new class/method with a different name.
In collections 3, it so happened that I used a new package, but that was because the GOAL of the release in many ways was to break up a monolith into smaller easier to understand packages. ie. the packages didn't result from semantic changes, but they did enable them - the package restructure came first.
Other projects will vary, beanutils/logging/betwixt/digester are all thinking of incompatible v2s, and I can't comment on them. Another package may be the appropriate solution for a particular commons component, however a blanket rule doesn't work for me, nor does including the version number. If you create a package it should describe its purpose.
Stephen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
