Illya, Stability of branches is upto dev community. If we want to backport more fixes to 1.x or 2.x lines that is up to us. Infact, that should be done. However, that doesn't preclude us from moving forward. We want to support existing users on branches which have seen adoption. But at the same time we want to move forward with leaner code base so that we can add new features faster in future.
Thanks, Ashutosh On Fri, Mar 3, 2017 at 7:00 PM, Yalovyy, Illya <yalov...@amazon.com> wrote: > Personally, I agree with each and every point. At the same time, I feel > like Hive 2.x > Branch is not stable enough to fork another unstable branch. Hive > customers could > find themselves in a very unpleasant situation when there is an obsolete > 1.x branch, > unstable and almost abandoned 2.x branch and incompatible and unstable 3.x > branch. > Taking into account considerable amount of other SQL based bigdata tools > on the > market it can push Hive loyal customers to try something new and start > migration. > I think the strongest thing of Hive was its evolutionary development when > new > features and execution engines successfully coexist with older ones. It > comes at > a cost, but it also keeps Hive the most used tool in Hadoop ecosystem. I > afraid that > leaving Hive customers without safe and stable branch we could break that > trust we > have built. > > On 3/3/17, 1:50 PM, "Ashutosh Chauhan" <hashut...@apache.org> wrote: > > Hi all, > > Hive project has come a long way. With wide-spread adoption also comes > expectations. Expectation of being backward compatible and not breaking > things. However that doesn't come free of cost and results in lot of > legacy > code which can't be refactored without fear of breaking things. As a > result > project has accumulated lot of debt over time. At the same time there > are > also lot of features which have seen little uptake. We may want to drop > some of those. > > In order to move forward and shed that debt we may need a major version > release which allows us to make backward incompatible changes and drop > rarely used features. At the same time there are lots of users which > are > consuming currently released 2.1 , 2.2 branches and expect them to > stay on > it for some time. So, I propose that we create branch-2 from current > tip > and do future 2.x releases from that branch and keep it backward > compatible. This will allow devs to land breaking changes on master and > pave way to release hive 3.0 in future. > > Ofcourse, each specific incompatible change and feature drop even on > master need to be evaluated on its own merit on corresponding jira. > This > email is just a solicitation of feedback for creating branch-2 and > allowing > breaking changes in master. Thoughts? > > Thanks, > Ashutosh > > >
