It would be great to get that module completed, yes [1]. But we also want to release as soon as possible to show renewed activity. I imagine the HBase module will take some more time to review and fix, since there's still quite some critical pieces missing I think.
[1] Draft module by Sameer and me available at http://eobjects.org/svn/MetaModel/branches/HBase-module/hbase/ 2013/7/18 sameer arora <[email protected]> > 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 > > > >> > > > > >> > > > > > > > > > > > > > >
