You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by Sudheesh Katkam <sk...@maprtech.com> on 2016/11/28 23:25:05 UTC
[DISCUSS] Apache Drill Version after 1.9.0, etc.
Hi all,
-----
(A) I had asked the question about what the release version should be after 1.9.0. Since this is part of the next release plan, a vote is required based on the discussion. For approval, the vote requires a lazy majority of active committers over 3 days.
Here are some comments from that thread:
Quoting Paul:
> For release numbers, 1.10 (then 1.11, 1.12, …) seems like a good idea.
>
> At first it may seem odd to go to 1.10 from 1.9. Might people get confused between 1.10 and 1.1.0? But, there is precedence. Tomcat’s latest 7-series release is 7.0.72. Java is on 8u112. And so on.
>
> I like the idea of moving to 2.0 later when the team introduces a major change, rather than by default just because the numbers roll around. For example, Hadoop when to 2.x when YARN was introduced. Impala appears to have moved to 2.0 when they added Spill to disk for some (all?) operators.
Quoting Parth:
> Specifically what did you want to discuss about the release number after 1.9? Ordinarily you would just go to 2.0. The only reason for holding off on 2.0, that I can think of, is if you want to make breaking changes in the 2.0 release and those are not going to be ready for the next release cycle. Are any dev's planning on such breaking changes? If so we should discuss that (or any other reason we might have for deferring 2.0) in a separate thread?
> I'm +0 on any version number we chose.
I am +1 on Paul’s suggestion for 1.10.0, unless, as Parth noted, we plan to make breaking changes in the next release cycle.
@Jacques, any comments? You had mentioned about this a while back [1].
-----
(B) Until discussion on (A) is complete, which may take a while, I propose we move the master to 1.10.0-SNAPSHOT to unblock committing to master branch. If there are no objections, I will do this tomorrow, once 1.9.0 release artifacts are propagated.
-----
(C) I noticed there are some changes committed to master branch before the commit that moves to the next snapshot version. Did we face this issue in the past? If so, how did we resolve the issue? Is 'force push' an option?
-----
Thank you,
Sudheesh
[1] http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ%40mail.gmail.com%3E <http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ@mail.gmail.com%3E>
Re: [DISCUSS] Apache Drill Version after 1.9.0, etc.
Posted by Jacques Nadeau <ja...@dremio.com>.
Hey Sudheesh,
Thanks for asking my opinion given my statements back in April. I
appreciate the thought but I prefer to defer to others who are more
actively contributing than myself.
With regards to (C): I ran numerous releases previously where we simply
forward ported any fixes that were wanted from a release branch back into
master. There is no formal requirement for a release commit to be on the
master branch. In general, once the release branch is started, I typically
suggest simply rolling forward the master branch to the next snapshot
version immediately. Note that different projects think about this
differently. As an example: on the Calcite project we typically lock the
master branch so that the release is in the master branch.
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Mon, Nov 28, 2016 at 7:49 PM, Aman Sinha <am...@apache.org> wrote:
> (A) I am leaning to 1.10 for the reasons already mentioned in your email.
> (B) sounds good.
> (C) Does it matter if there are a few commits in master branch already ?
> What's the implication of just updating the pom files (not force-push).
>
> On Mon, Nov 28, 2016 at 3:25 PM, Sudheesh Katkam <sk...@maprtech.com>
> wrote:
>
> > Hi all,
> >
> > -----
> >
> > (A) I had asked the question about what the release version should be
> > after 1.9.0. Since this is part of the next release plan, a vote is
> > required based on the discussion. For approval, the vote requires a lazy
> > majority of active committers over 3 days.
> >
> > Here are some comments from that thread:
> >
> > Quoting Paul:
> >
> > > For release numbers, 1.10 (then 1.11, 1.12, …) seems like a good idea.
> > >
> > > At first it may seem odd to go to 1.10 from 1.9. Might people get
> > confused between 1.10 and 1.1.0? But, there is precedence. Tomcat’s
> latest
> > 7-series release is 7.0.72. Java is on 8u112. And so on.
> > >
> > > I like the idea of moving to 2.0 later when the team introduces a major
> > change, rather than by default just because the numbers roll around. For
> > example, Hadoop when to 2.x when YARN was introduced. Impala appears to
> > have moved to 2.0 when they added Spill to disk for some (all?)
> operators.
> >
> >
> > Quoting Parth:
> >
> > > Specifically what did you want to discuss about the release number
> after
> > 1.9? Ordinarily you would just go to 2.0. The only reason for holding
> off
> > on 2.0, that I can think of, is if you want to make breaking changes in
> the
> > 2.0 release and those are not going to be ready for the next release
> cycle.
> > Are any dev's planning on such breaking changes? If so we should discuss
> > that (or any other reason we might have for deferring 2.0) in a separate
> > thread?
> > > I'm +0 on any version number we chose.
> >
> >
> > I am +1 on Paul’s suggestion for 1.10.0, unless, as Parth noted, we plan
> > to make breaking changes in the next release cycle.
> >
> > @Jacques, any comments? You had mentioned about this a while back [1].
> >
> > -----
> >
> > (B) Until discussion on (A) is complete, which may take a while, I
> propose
> > we move the master to 1.10.0-SNAPSHOT to unblock committing to master
> > branch. If there are no objections, I will do this tomorrow, once 1.9.0
> > release artifacts are propagated.
> >
> > -----
> >
> > (C) I noticed there are some changes committed to master branch before
> the
> > commit that moves to the next snapshot version. Did we face this issue in
> > the past? If so, how did we resolve the issue? Is 'force push' an option?
> >
> > -----
> >
> > Thank you,
> > Sudheesh
> >
> > [1] http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%
> > 3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ%40mail.gmail.com
> %3E
> > <http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%
> > 3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ@mail.gmail.com%3E>
>
Re: [DISCUSS] Apache Drill Version after 1.9.0, etc.
Posted by Parth Chandra <pa...@apache.org>.
Aren't we sidestepping the real questions -
What, if any, are the breaking changes we are looking at in the near
(or distant) term?
If we don't have any such changes on the horizon, then when are we
going to do a 2.0 release?
Before we finalize this I would like us to have the criteria for moving to
2.0 decided.
Ideally, we would want a roadmap of items that we consider breaking
changes. (I would also recommend starting a 2.0 branch for those breaking
changes). I know some client side breaking changes slipped in without
causing any harm in a couple of previous releases, so is this even a
criterion? If it is, then let's have a plan (even a somewhat hopeful one)
for 2.0.
Parth
On Tue, Nov 29, 2016 at 9:08 AM, Neeraja Rentachintala <
nrentachintala@maprtech.com> wrote:
> +1 on continuing to 1.10 version after 1.9 release.
>
>
> On Mon, Nov 28, 2016 at 7:49 PM, Aman Sinha <am...@apache.org> wrote:
>
> > (A) I am leaning to 1.10 for the reasons already mentioned in your email.
> > (B) sounds good.
> > (C) Does it matter if there are a few commits in master branch already ?
> > What's the implication of just updating the pom files (not force-push).
> >
> > On Mon, Nov 28, 2016 at 3:25 PM, Sudheesh Katkam <sk...@maprtech.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > -----
> > >
> > > (A) I had asked the question about what the release version should be
> > > after 1.9.0. Since this is part of the next release plan, a vote is
> > > required based on the discussion. For approval, the vote requires a
> lazy
> > > majority of active committers over 3 days.
> > >
> > > Here are some comments from that thread:
> > >
> > > Quoting Paul:
> > >
> > > > For release numbers, 1.10 (then 1.11, 1.12, …) seems like a good
> idea.
> > > >
> > > > At first it may seem odd to go to 1.10 from 1.9. Might people get
> > > confused between 1.10 and 1.1.0? But, there is precedence. Tomcat’s
> > latest
> > > 7-series release is 7.0.72. Java is on 8u112. And so on.
> > > >
> > > > I like the idea of moving to 2.0 later when the team introduces a
> major
> > > change, rather than by default just because the numbers roll around.
> For
> > > example, Hadoop when to 2.x when YARN was introduced. Impala appears to
> > > have moved to 2.0 when they added Spill to disk for some (all?)
> > operators.
> > >
> > >
> > > Quoting Parth:
> > >
> > > > Specifically what did you want to discuss about the release number
> > after
> > > 1.9? Ordinarily you would just go to 2.0. The only reason for holding
> > off
> > > on 2.0, that I can think of, is if you want to make breaking changes in
> > the
> > > 2.0 release and those are not going to be ready for the next release
> > cycle.
> > > Are any dev's planning on such breaking changes? If so we should
> discuss
> > > that (or any other reason we might have for deferring 2.0) in a
> separate
> > > thread?
> > > > I'm +0 on any version number we chose.
> > >
> > >
> > > I am +1 on Paul’s suggestion for 1.10.0, unless, as Parth noted, we
> plan
> > > to make breaking changes in the next release cycle.
> > >
> > > @Jacques, any comments? You had mentioned about this a while back [1].
> > >
> > > -----
> > >
> > > (B) Until discussion on (A) is complete, which may take a while, I
> > propose
> > > we move the master to 1.10.0-SNAPSHOT to unblock committing to master
> > > branch. If there are no objections, I will do this tomorrow, once 1.9.0
> > > release artifacts are propagated.
> > >
> > > -----
> > >
> > > (C) I noticed there are some changes committed to master branch before
> > the
> > > commit that moves to the next snapshot version. Did we face this issue
> in
> > > the past? If so, how did we resolve the issue? Is 'force push' an
> option?
> > >
> > > -----
> > >
> > > Thank you,
> > > Sudheesh
> > >
> > > [1] http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%
> > > 3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ%40mail.gmail.com
> > %3E
> > > <http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%
> > > 3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ@mail.gmail.com
> %3E>
> >
>
Re: [DISCUSS] Apache Drill Version after 1.9.0, etc.
Posted by Neeraja Rentachintala <nr...@maprtech.com>.
+1 on continuing to 1.10 version after 1.9 release.
On Mon, Nov 28, 2016 at 7:49 PM, Aman Sinha <am...@apache.org> wrote:
> (A) I am leaning to 1.10 for the reasons already mentioned in your email.
> (B) sounds good.
> (C) Does it matter if there are a few commits in master branch already ?
> What's the implication of just updating the pom files (not force-push).
>
> On Mon, Nov 28, 2016 at 3:25 PM, Sudheesh Katkam <sk...@maprtech.com>
> wrote:
>
> > Hi all,
> >
> > -----
> >
> > (A) I had asked the question about what the release version should be
> > after 1.9.0. Since this is part of the next release plan, a vote is
> > required based on the discussion. For approval, the vote requires a lazy
> > majority of active committers over 3 days.
> >
> > Here are some comments from that thread:
> >
> > Quoting Paul:
> >
> > > For release numbers, 1.10 (then 1.11, 1.12, …) seems like a good idea.
> > >
> > > At first it may seem odd to go to 1.10 from 1.9. Might people get
> > confused between 1.10 and 1.1.0? But, there is precedence. Tomcat’s
> latest
> > 7-series release is 7.0.72. Java is on 8u112. And so on.
> > >
> > > I like the idea of moving to 2.0 later when the team introduces a major
> > change, rather than by default just because the numbers roll around. For
> > example, Hadoop when to 2.x when YARN was introduced. Impala appears to
> > have moved to 2.0 when they added Spill to disk for some (all?)
> operators.
> >
> >
> > Quoting Parth:
> >
> > > Specifically what did you want to discuss about the release number
> after
> > 1.9? Ordinarily you would just go to 2.0. The only reason for holding
> off
> > on 2.0, that I can think of, is if you want to make breaking changes in
> the
> > 2.0 release and those are not going to be ready for the next release
> cycle.
> > Are any dev's planning on such breaking changes? If so we should discuss
> > that (or any other reason we might have for deferring 2.0) in a separate
> > thread?
> > > I'm +0 on any version number we chose.
> >
> >
> > I am +1 on Paul’s suggestion for 1.10.0, unless, as Parth noted, we plan
> > to make breaking changes in the next release cycle.
> >
> > @Jacques, any comments? You had mentioned about this a while back [1].
> >
> > -----
> >
> > (B) Until discussion on (A) is complete, which may take a while, I
> propose
> > we move the master to 1.10.0-SNAPSHOT to unblock committing to master
> > branch. If there are no objections, I will do this tomorrow, once 1.9.0
> > release artifacts are propagated.
> >
> > -----
> >
> > (C) I noticed there are some changes committed to master branch before
> the
> > commit that moves to the next snapshot version. Did we face this issue in
> > the past? If so, how did we resolve the issue? Is 'force push' an option?
> >
> > -----
> >
> > Thank you,
> > Sudheesh
> >
> > [1] http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%
> > 3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ%40mail.gmail.com
> %3E
> > <http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%
> > 3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ@mail.gmail.com%3E>
>
Re: [DISCUSS] Apache Drill Version after 1.9.0, etc.
Posted by Aman Sinha <am...@apache.org>.
(A) I am leaning to 1.10 for the reasons already mentioned in your email.
(B) sounds good.
(C) Does it matter if there are a few commits in master branch already ?
What's the implication of just updating the pom files (not force-push).
On Mon, Nov 28, 2016 at 3:25 PM, Sudheesh Katkam <sk...@maprtech.com>
wrote:
> Hi all,
>
> -----
>
> (A) I had asked the question about what the release version should be
> after 1.9.0. Since this is part of the next release plan, a vote is
> required based on the discussion. For approval, the vote requires a lazy
> majority of active committers over 3 days.
>
> Here are some comments from that thread:
>
> Quoting Paul:
>
> > For release numbers, 1.10 (then 1.11, 1.12, …) seems like a good idea.
> >
> > At first it may seem odd to go to 1.10 from 1.9. Might people get
> confused between 1.10 and 1.1.0? But, there is precedence. Tomcat’s latest
> 7-series release is 7.0.72. Java is on 8u112. And so on.
> >
> > I like the idea of moving to 2.0 later when the team introduces a major
> change, rather than by default just because the numbers roll around. For
> example, Hadoop when to 2.x when YARN was introduced. Impala appears to
> have moved to 2.0 when they added Spill to disk for some (all?) operators.
>
>
> Quoting Parth:
>
> > Specifically what did you want to discuss about the release number after
> 1.9? Ordinarily you would just go to 2.0. The only reason for holding off
> on 2.0, that I can think of, is if you want to make breaking changes in the
> 2.0 release and those are not going to be ready for the next release cycle.
> Are any dev's planning on such breaking changes? If so we should discuss
> that (or any other reason we might have for deferring 2.0) in a separate
> thread?
> > I'm +0 on any version number we chose.
>
>
> I am +1 on Paul’s suggestion for 1.10.0, unless, as Parth noted, we plan
> to make breaking changes in the next release cycle.
>
> @Jacques, any comments? You had mentioned about this a while back [1].
>
> -----
>
> (B) Until discussion on (A) is complete, which may take a while, I propose
> we move the master to 1.10.0-SNAPSHOT to unblock committing to master
> branch. If there are no objections, I will do this tomorrow, once 1.9.0
> release artifacts are propagated.
>
> -----
>
> (C) I noticed there are some changes committed to master branch before the
> commit that moves to the next snapshot version. Did we face this issue in
> the past? If so, how did we resolve the issue? Is 'force push' an option?
>
> -----
>
> Thank you,
> Sudheesh
>
> [1] http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%
> 3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ%40mail.gmail.com%3E
> <http://mail-archives.apache.org/mod_mbox/drill-dev/201604.mbox/%
> 3CCAJrw0OTiXLnmW25K0aQtsVmh3A4vxfwZzvHntxeYJjPdd-PnYQ@mail.gmail.com%3E>