metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasper Sørensen <i.am.kasper.soren...@gmail.com>
Subject Re: What do we want to bring to the first release of Apache MetaModel?
Date Thu, 18 Jul 2013 09:48:01 GMT
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 <arvind@apache.org>

> 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 <arvind@apache.org>
> 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 <
> > i.am.kasper.sorensen@gmail.com> 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 <nslater@apache.org>
> >>
> >> > 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 <henry.saputra@gmail.com> 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 <
> >> > > i.am.kasper.sorensen@gmail.com> 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
> >> >
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message