I would say baby steps for the changes. Changing package names to org.apache.metamodel will already do damages to clients using MetaModel or develop extension.
For first release I am proposing we just make solid MetModel release following Apache naming and other small enhancements and bug fixes. We could move fast in terms of releases, so next one within a month of the first release maybe we could introduce API changes. Just my 2 cents - Henry On Thu, Jun 27, 2013 at 11:24 AM, Kasper Sørensen < [email protected]> wrote: > 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 >
