The more I think about this (and the work involved, and the postponing of the migration pain etc. etc.) I feel that we should just do a clean cut and break backwards compatibility with the namespace change. It's IMO a choice of a lot of compiler errors or a lot of deprecation warnings. And my experience has been that deprecation warnings are a lot worse since they take longer to fix :-)
If we get really critical bugfixes, I imagine that we will still support the org.eobjects codebase via the old infrastructure for a while (some months). If not anything else, then we need that at Human Inference because our internal migrations are also bound to release cycles other than MetaModel's. 2013/7/8 Arvind Prabhakar <[email protected]> > Accidentally pasted the wrong URL. The correct one is: > > [1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration > > Regards, > Arvind Prabhakar > > On Mon, Jul 8, 2013 at 2:24 AM, Arvind Prabhakar <[email protected]> > wrote: > > > Wanted to add a datapoint that it is OK to keep the old package names and > > interfaces as long as they are deprecated explicitly. I did a similar > > exercise for Apache Sqoop and documented the way to go about it on the > wiki > > [1]. > > > > This will be helpful if you would like to provide a smooth transition to > > your existing community and also continue to work with any third-party > > systems that may be using your APIs. If these are not major concerns for > > the project, then perhaps it is best to do a clean cut-over and break > > compatibility. > > > > [1] > > > https://cwiki.apache.org/confluence/display/SQOOP/Transition+from+Cloudera > > > > Regards, > > Arvind Prabhakar > > > > > > On Sat, Jun 29, 2013 at 8:41 AM, Kasper Sørensen < > > [email protected]> wrote: > > > >> Yes this is very similar to the version scheme we've used. Basically > I've > >> also been thinking that the apache version would be a 4.0.0, since the > >> package naming makes everything incompatible. My question in this regard > >> was that if we're anyways doing that right now, we might as well ensure > we > >> dont want to switch to 5.0.0 too soon because we did not take the chance > >> to > >> make other API improvements. > >> > >> > >> 2013/6/28 Noah Slater <[email protected]> > >> > >> > 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 > >> > > >> > > > > >
