Hi all, When we're moving the code base to Apache, some major breaking changes will take place to the codebase. For one, every package will change from org.* eobjects*.metamodel... to org.*apache*.metamodel...
So in my opinion, no matter how we gentle we make the migration, it will break backwards compatibility and Apache MetaModel will not be a drop-in replacement for the old MetaModel. This open up a devilish question: When we're anyways breaking backwards compatibility, are there things we would want to change in MetaModel's remaining interface in the same go? Or should we try to control the changes a bit - making it still quite effortless to migrate, if you're willing to do a search/replace on the package names? To give an example, I have a small topic on my mind that I would like to change, but it's never been important enough for me to want to break compatibility over it: The interfaces for Schema, Table and Column expose arrays instead of > collections/lists (for instance Schema.getTables()). But in hindsight it > would have been better to go for a collection type (List probably) to make > it possible to expose a truly immutable schema model. Also, since List is > an interface, it's easier to mock if needed. If we feel that the time is right for such API refactorings, we should probably try now to compile a list of wishes for API changes that we could introduce? What do you think? Is it best to make the smoothest possible migration, or is now a good time to also show courage to make API changes? Best regards, Kasper
