I think adding the Hbase module which is lying incomplete for a while now in the first release
On Thu, Jul 18, 2013 at 3:18 PM, Kasper Sørensen < [email protected]> wrote: > 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 > > >> > > > >> > > > > > > > > >
