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 Wed, 24 Jul 2013 13:31:24 GMT
If you have other breaking changes you can get in soon, I'd recommend doing
them all at once. Best not to have a succession of backwards incompatible
releases.

The process for the release is that you make a release candidate and upload
it to your personal space, and call a vote. But we must not call these
releases until they have been voted on by the community. (To the same end,
nightly builds should be called just that. They are not nightly releases.)
There's plenty of docs on the Incubator pages about how to do a release.

http://incubator.apache.org/guides/releasemanagement.html

Note: I expect our first release to be quite painful. It always is. ;)


On 24 July 2013 13:35, Kasper Sørensen <i.am.kasper.sorensen@gmail.com>wrote:

> 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 <i.am.kasper.sorensen@gmail.com>
>
> > 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 <sameer11sep@gmail.com>
> >
> >> 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 <
> >> i.am.kasper.sorensen@gmail.com> 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 <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
> >> > > >> >
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>



-- 
NS

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