+1 This would protect those who might not want to lose workflow features from the stable releases for the coming year.
I¹m not looking forward to a branch merge tearing out the hive CLI client away in a single chop. Having a master branch where we can plan for the future is essential and this is an established way to do that without inconveniencing the existing user base. Also, git - I couldn¹t have handled this before we moved over onto it. Cheers, Gopal On 5/26/15, 11:41 AM, "Alan Gates" <alanfga...@gmail.com> wrote: >We have discussed this for several weeks now. Some concerns have been >raised which I have tried to address. I think it is time to vote on it >as our release plan. To be specific, I propose: > >Hive makes a branch-1 from the current master. This would be used for >1.3 and future 1.x releases. This branch would not deprecate existing >functionality. Any new features in this branch would also need to be >put on master. An upgrade path for users will be maintained from one >1.x release to the next, as well as from the latest 1.x release to the >latest 2.x release. > >Going forward releases numbered 2.x will be made from master. The >purpose of these releases will be to enable users to get access to new >features being developed in Hive and allow developers to get feedback. >It is expected that for a while these releases will not be production >ready and will be clearly so labeled. Some legacy features, such as >Hadoop 1 and MapReduce, will no longer be supported in the master. Any >critical bug fixes (security, incorrect results, crashes) fixed in >master will also be ported to branch-1 for at least a year. This time >period may be extended in the future based on the stability and adoption >of 2.x releases. > >Based on Hive's bylaws this release plan vote will be open for 3 days >and all active committers have binding votes. > >Here's my +1. > >Alan.
