As far as I can see, we're done with the initial migration to the ASF infrastructure, namespace etc.
If you ask me, we can make our first release which isn't much of a change functionality-wise, but includes the breaking namespace change. And in terms of versioning - I believe we should call it version 4.0, since it breaks backwards compatibility, right? On the other hand I have some more suggestions for (breaking) improvements to the API that I'd like to consider once we have JIRA etc. lined up. So maybe we should simply make an initial release candidate, or alpha release, or what would be a proper name... 2013/7/18 Kasper Sørensen <[email protected]> > 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 >> > > >> > >> > > >> >> > > > >> > > > >> > > >> > >> > >
