What versioning scheme do you use? Have you seen http://semver.org/ before?
If we used semver, the org.apache change would be a major release bump. On 27 June 2013 19:58, Henry Saputra <[email protected]> wrote: > 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 > > > -- NS
