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 >> > >> > >
