metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: What do we want to bring to the first release of Apache MetaModel?
Date Fri, 28 Jun 2013 12:59:55 GMT
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