Re: What do we want to bring to the first release of Apache MetaModel?

[Arvind Prabhakar <ar...@apache.org>]

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 <ns...@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 <he...@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
> >
>

Re: What do we want to bring to the first release of Apache MetaModel?

[Matt Franklin <m....@gmail.com>]

On Thu, Jul 25, 2013 at 2:10 PM, Kasper Sørensen <
i.am.kasper.sorensen@gmail.com> wrote:

> Re2013/7/25 Noah Slater <ns...@apache.org>
> >
> > On 24 July 2013 19:07, Kasper Sørensen <i.am.kasper.sorensen@gmail.com
> >wrote:
> >
> > > I also felt that having a release soon is a
> > > priority in order to show activity from the incubation perspective.
> > >
> >
> > Don't worry about getting the release out to satisfy some arbitrary
> > "activity" metric. We can demonstrate activity via mailing list posts,
> > commits, etc.
>
> OK then I guess we can have a little more patience.
>
> >
> >
> > > Maybe a snapshot (or other non-final) way of releasing would be good?
> Maybe
> > > my use of the word "release" wasn't entirely in line with what we can
> > > define as a "proper" release.
> >
> >
> > Aye. The word "release" is very special, so we need to be careful about
> how
> > we use it. There is no such thing as a "proper" release, as that implies
> a
> > less formal one. But the ASF makes no such distinction.
> >
>
> Read further down ...
>
> >
> > > What I had in mind is at least to make public
> > > a set of artifacts on the maven central, so that people can start using
> > > MetaModel with the org.apache namespace. Potentially well-knowing that
> > > there will be some breaking changes coming in the near future.
> >
> >
> > That's fine. But we need to call them snapshots, or nightlies, or builds,
> > or whatever. And when we talk about them, or link to them, we need to be
> > very clear with our language that these are not releases, they are not
> > meant to regular users, and should be downloaded and used by devs only.
> >
>
> ... further ...
>
> >
> > > Is that doable on short
> > > notice, and then we can rather plan a roadmap to a more official/final
> > > release?
> > >
> >
> > You could do that now, if you wish. Just bung some files in your web
> space
> > on people.apache.org. As long as you don't call them releases, or even
> hint
> > at the idea that they're releases, then everything should be fine.
>
> I would ideally want something we can publish on the maven central. No
> matter what we dub it (snapshot, build, release candidate etc.), but
> it should be there so we can start migrating projects that use MM to
> the new namespace. Maybe for a period only to prove that "it still
> works" (continuous integration etc.) and not necesarily that we've
> improved anything.


> Let me be concrete; I see for instance that commons-lang exist in the
> maven central under the seemingly "non final" version: 20030203.000129
>
> http://search.maven.org/#artifactdetails%7Ccommons-lang%7Ccommons-lang%7C20030203.000129%7Cjar
>
> To me this looks like a version name that identifies a build.
>
> Could we do a similar maven release of a build (consciously using the
> maven prefix here because it's the maven definition of a release to
> publish it to a repo :-)) to the central repo?
>

SNAPSHOTs would go to repository.apache.org, which people can point to if
they choose.  SNAPSHOTS should represent just a working build of any given
project and should only be used by downstream projects to detect and report
bugs as they impact their usage.

If we want to put something out there that represents an intermediate
state, but is more static (SNAPSHOTs change with every CI build usually),
then we should do an intermediate release.  3.99.x or 4.0.0-alpha, or
foo.bar.x.  What name any release has is completely up to us and should
only represent the community's agreement as to the sate of the software.

This type of release would count as a fully fledged podling release and
must comply with the basic legal compliance (no GPL dependencies, correct
license attributions, etc).  We don't have to have all branding items like
package names completed in order to do a release.


>
> >
> > --
> > NS
>

Re: What do we want to bring to the first release of Apache MetaModel?

[Noah Slater <ns...@apache.org>]

I don't have much experience with Maven or Java at the ASF, so I'll let one
of the other mentors chime in.


On 25 July 2013 20:10, Kasper Sørensen <i....@gmail.com>wrote:

> Re2013/7/25 Noah Slater <ns...@apache.org>
> >
> > On 24 July 2013 19:07, Kasper Sørensen <i.am.kasper.sorensen@gmail.com
> >wrote:
> >
> > > I also felt that having a release soon is a
> > > priority in order to show activity from the incubation perspective.
> > >
> >
> > Don't worry about getting the release out to satisfy some arbitrary
> > "activity" metric. We can demonstrate activity via mailing list posts,
> > commits, etc.
>
> OK then I guess we can have a little more patience.
>
> >
> >
> > > Maybe a snapshot (or other non-final) way of releasing would be good?
> Maybe
> > > my use of the word "release" wasn't entirely in line with what we can
> > > define as a "proper" release.
> >
> >
> > Aye. The word "release" is very special, so we need to be careful about
> how
> > we use it. There is no such thing as a "proper" release, as that implies
> a
> > less formal one. But the ASF makes no such distinction.
> >
>
> Read further down ...
>
> >
> > > What I had in mind is at least to make public
> > > a set of artifacts on the maven central, so that people can start using
> > > MetaModel with the org.apache namespace. Potentially well-knowing that
> > > there will be some breaking changes coming in the near future.
> >
> >
> > That's fine. But we need to call them snapshots, or nightlies, or builds,
> > or whatever. And when we talk about them, or link to them, we need to be
> > very clear with our language that these are not releases, they are not
> > meant to regular users, and should be downloaded and used by devs only.
> >
>
> ... further ...
>
> >
> > > Is that doable on short
> > > notice, and then we can rather plan a roadmap to a more official/final
> > > release?
> > >
> >
> > You could do that now, if you wish. Just bung some files in your web
> space
> > on people.apache.org. As long as you don't call them releases, or even
> hint
> > at the idea that they're releases, then everything should be fine.
>
> I would ideally want something we can publish on the maven central. No
> matter what we dub it (snapshot, build, release candidate etc.), but
> it should be there so we can start migrating projects that use MM to
> the new namespace. Maybe for a period only to prove that "it still
> works" (continuous integration etc.) and not necesarily that we've
> improved anything.
>
> Let me be concrete; I see for instance that commons-lang exist in the
> maven central under the seemingly "non final" version: 20030203.000129
>
> http://search.maven.org/#artifactdetails%7Ccommons-lang%7Ccommons-lang%7C20030203.000129%7Cjar
>
> To me this looks like a version name that identifies a build.
>
> Could we do a similar maven release of a build (consciously using the
> maven prefix here because it's the maven definition of a release to
> publish it to a repo :-)) to the central repo?
>
> >
> > --
> > NS
>



-- 
NS

Re: What do we want to bring to the first release of Apache MetaModel?

[Kasper Sørensen <i....@gmail.com>]

Re2013/7/25 Noah Slater <ns...@apache.org>
>
> On 24 July 2013 19:07, Kasper Sørensen <i....@gmail.com>wrote:
>
> > I also felt that having a release soon is a
> > priority in order to show activity from the incubation perspective.
> >
>
> Don't worry about getting the release out to satisfy some arbitrary
> "activity" metric. We can demonstrate activity via mailing list posts,
> commits, etc.

OK then I guess we can have a little more patience.

>
>
> > Maybe a snapshot (or other non-final) way of releasing would be good? Maybe
> > my use of the word "release" wasn't entirely in line with what we can
> > define as a "proper" release.
>
>
> Aye. The word "release" is very special, so we need to be careful about how
> we use it. There is no such thing as a "proper" release, as that implies a
> less formal one. But the ASF makes no such distinction.
>

Read further down ...

>
> > What I had in mind is at least to make public
> > a set of artifacts on the maven central, so that people can start using
> > MetaModel with the org.apache namespace. Potentially well-knowing that
> > there will be some breaking changes coming in the near future.
>
>
> That's fine. But we need to call them snapshots, or nightlies, or builds,
> or whatever. And when we talk about them, or link to them, we need to be
> very clear with our language that these are not releases, they are not
> meant to regular users, and should be downloaded and used by devs only.
>

... further ...

>
> > Is that doable on short
> > notice, and then we can rather plan a roadmap to a more official/final
> > release?
> >
>
> You could do that now, if you wish. Just bung some files in your web space
> on people.apache.org. As long as you don't call them releases, or even hint
> at the idea that they're releases, then everything should be fine.

I would ideally want something we can publish on the maven central. No
matter what we dub it (snapshot, build, release candidate etc.), but
it should be there so we can start migrating projects that use MM to
the new namespace. Maybe for a period only to prove that "it still
works" (continuous integration etc.) and not necesarily that we've
improved anything.

Let me be concrete; I see for instance that commons-lang exist in the
maven central under the seemingly "non final" version: 20030203.000129
http://search.maven.org/#artifactdetails%7Ccommons-lang%7Ccommons-lang%7C20030203.000129%7Cjar

To me this looks like a version name that identifies a build.

Could we do a similar maven release of a build (consciously using the
maven prefix here because it's the maven definition of a release to
publish it to a repo :-)) to the central repo?

>
> --
> NS

Re: What do we want to bring to the first release of Apache MetaModel?

[Noah Slater <ns...@apache.org>]

On 24 July 2013 19:07, Kasper Sørensen <i....@gmail.com>wrote:

> I also felt that having a release soon is a
> priority in order to show activity from the incubation perspective.
>

Don't worry about getting the release out to satisfy some arbitrary
"activity" metric. We can demonstrate activity via mailing list posts,
commits, etc.


> Maybe a snapshot (or other non-final) way of releasing would be good? Maybe
> my use of the word "release" wasn't entirely in line with what we can
> define as a "proper" release.


Aye. The word "release" is very special, so we need to be careful about how
we use it. There is no such thing as a "proper" release, as that implies a
less formal one. But the ASF makes no such distinction.


> What I had in mind is at least to make public
> a set of artifacts on the maven central, so that people can start using
> MetaModel with the org.apache namespace. Potentially well-knowing that
> there will be some breaking changes coming in the near future.


That's fine. But we need to call them snapshots, or nightlies, or builds,
or whatever. And when we talk about them, or link to them, we need to be
very clear with our language that these are not releases, they are not
meant to regular users, and should be downloaded and used by devs only.


> Is that doable on short
> notice, and then we can rather plan a roadmap to a more official/final
> release?
>

You could do that now, if you wish. Just bung some files in your web space
on people.apache.org. As long as you don't call them releases, or even hint
at the idea that they're releases, then everything should be fine.

-- 
NS

Re: What do we want to bring to the first release of Apache MetaModel?

[Kasper Sørensen <i....@gmail.com>]

I get the point about either adding it soon or not adding it. At least I
then just want to bring up some discussion topics around potential breaking
changes that we could make (will post individual mail threads based on
issues/ideas we have on the old bugtracker [1]). But taking them all on
would probably mean that the release wouldn't be doable soon. So it's kind
of a priority issue, since I also felt that having a release soon is a
priority in order to show activity from the incubation perspective.

Maybe a snapshot (or other non-final) way of releasing would be good? Maybe
my use of the word "release" wasn't entirely in line with what we can
define as a "proper" release. What I had in mind is at least to make public
a set of artifacts on the maven central, so that people can start using
MetaModel with the org.apache namespace. Potentially well-knowing that
there will be some breaking changes coming in the near future. Like what I
would normally call an "alpha" release or so. Is that doable on short
notice, and then we can rather plan a roadmap to a more official/final
release?

[1] http://eobjects.org/trac/query?milestone=MetaModel+X.0


2013/7/24 Noah Slater <ns...@apache.org>

> Good catches, Matt. Thanks!
>
>
> On 24 July 2013 14:46, Matt Franklin <m....@gmail.com> wrote:
>
> > We should look into using the svn pub-sub staging area for releases (the
> > dist area is required for approved releases already) rather than anything
> > on people.apache.org
>
>
> *Facepalm*
>
> Yes, this is the recommended approach these days! ;)
>
>
> > Assuming we are deploying to the Nexus Maven repository, we can have the
> CI
> > engine deploy SNAPSHOTS to repository.apache.org.
> >
>
> "Snapshots" work also. ;) Just "release" is a very special word. We need to
> be careful with it.
>
>
> > We should document our release process on the website the first time we
> run
> > through it [2] [3].
> >
> > [1] http://rave.apache.org/docs/governance/lazyConsensus.html (there is
> a
> > comdev page, I just found this one first)
> > [2] http://bval.apache.org/release-management.html
> > [3] http://rave.apache.org/release-management.html
>
>
> Here's another example:
>
> http://wiki.apache.org/couchdb/Release_Procedure
>
> (I've been honing this document for the best part of a decade.)
>
> --
> NS
>

Re: What do we want to bring to the first release of Apache MetaModel?

[Noah Slater <ns...@apache.org>]

Good catches, Matt. Thanks!


On 24 July 2013 14:46, Matt Franklin <m....@gmail.com> wrote:

> We should look into using the svn pub-sub staging area for releases (the
> dist area is required for approved releases already) rather than anything
> on people.apache.org


*Facepalm*

Yes, this is the recommended approach these days! ;)


> Assuming we are deploying to the Nexus Maven repository, we can have the CI
> engine deploy SNAPSHOTS to repository.apache.org.
>

"Snapshots" work also. ;) Just "release" is a very special word. We need to
be careful with it.


> We should document our release process on the website the first time we run
> through it [2] [3].
>
> [1] http://rave.apache.org/docs/governance/lazyConsensus.html (there is a
> comdev page, I just found this one first)
> [2] http://bval.apache.org/release-management.html
> [3] http://rave.apache.org/release-management.html


Here's another example:

http://wiki.apache.org/couchdb/Release_Procedure

(I've been honing this document for the best part of a decade.)

-- 
NS

Re: What do we want to bring to the first release of Apache MetaModel?

[Matt Franklin <m....@gmail.com>]

On Wed, Jul 24, 2013 at 8:31 AM, Noah Slater <ns...@apache.org> wrote:

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


We should look into using the svn pub-sub staging area for releases (the
dist area is required for approved releases already) rather than anything
on people.apache.org


> and call a vote. But we must not call these
>

To be clear, the vote needs to have both PPMC and Incubator PMC approval
(IPMC).  All of the mentors are IPMC members, so assuming we all vote +1
for the release, we only need to ask general@ for lazy consensus.

For anyone unfamiliar with lazy consensus, it is a powerful concept
employed heavily at the ASF[1]


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

Assuming we are deploying to the Nexus Maven repository, we can have the CI
engine deploy SNAPSHOTS to repository.apache.org.


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


We should document our release process on the website the first time we run
through it [2] [3].


[1] http://rave.apache.org/docs/governance/lazyConsensus.html (there is a
comdev page, I just found this one first)
[2] http://bval.apache.org/release-management.html
[3] http://rave.apache.org/release-management.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....@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 <sa...@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 <ar...@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 <ns...@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
>

Re: What do we want to bring to the first release of Apache MetaModel?

[Noah Slater <ns...@apache.org>]

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....@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....@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 <sa...@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 <ar...@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 <ns...@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 <he...@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

Re: What do we want to bring to the first release of Apache MetaModel?

[Kasper Sørensen <i....@gmail.com>]

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....@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 <sa...@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 <ar...@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 <ar...@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 <ns...@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 <he...@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
>> > > >> >
>> > > >>
>> > > >
>> > > >
>> > >
>> >
>>
>
>

Re: What do we want to bring to the first release of Apache MetaModel?

[Kasper Sørensen <i....@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 <sa...@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 <ar...@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 <ar...@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 <ns...@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 <he...@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
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: What do we want to bring to the first release of Apache MetaModel?

[sameer arora <sa...@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 <ar...@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 <ar...@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 <ns...@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 <he...@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
> > >> >
> > >>
> > >
> > >
> >
>

Re: What do we want to bring to the first release of Apache MetaModel?

[Kasper Sørensen <i....@gmail.com>]

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 <ar...@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 <ar...@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 <ns...@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 <he...@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
> >> >
> >>
> >
> >
>

Re: What do we want to bring to the first release of Apache MetaModel?

[Arvind Prabhakar <ar...@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 <ar...@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 <ns...@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 <he...@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
>> >
>>
>
>