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 <[email protected]> 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 <[email protected]> > 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-p...@mail.gmail.com%3E> >
