hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <>
Subject Re: Backward incompatible changes
Date Sat, 04 Mar 2017 00:46:23 GMT
Im not a fan of this our feature branching was supposed to protect us from
broken trumk syndrome.

I am a believer in releaseable trunk. Make it work and keep it working.

On Friday, March 3, 2017, Sergey Shelukhin <> wrote:

> Can we at least release 2.2 first? There’s massive amount of unreleased
> code right now on master.
> On 17/3/3, 13:50, "Ashutosh Chauhan" < <javascript:;>>
> 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

Sorry this was sent from mobile. Will do less grammar and spell check than

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message