hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Backward incompatible changes
Date Sat, 04 Mar 2017 18:19:31 GMT
Also i dont follow how we remove

On Saturday, March 4, 2017, Edward Capriolo <edlinuxguru@gmail.com> wrote:

>
>
> On Fri, Mar 3, 2017 at 8:46 PM, Thejas Nair <thejas.nair@gmail.com
> <javascript:_e(%7B%7D,'cvml','thejas.nair@gmail.com');>> wrote:
>
>> +1
>> There are some features that are incomplete and what I would not recommend
>> for any real production use.The 'legacy authorization mode' is a great
>> example of that -
>> https://cwiki.apache.org/confluence/display/Hive/Hive+Defaul
>> t+Authorization+-+Legacy+Mode
>> . It is inherently insecure mode that nobody should be using.
>>
>> There is also potential to cleanup of the thrift api. However, there are
>> many users of this api, we would need to go the deprecation then remove
>> after couple of releases route or so for that.
>>
>> I am sure there are many other candidates. We will have to evaluate each
>> of
>> those features on the risk/benefit of keeping them and arriving at a
>> decision.
>>
>> Also, +1 on getting a 2.2 release out before we branch.
>>
>>
>>
>> On Fri, Mar 3, 2017 at 1:50 PM, Ashutosh Chauhan <hashutosh@apache.org
>> <javascript:_e(%7B%7D,'cvml','hashutosh@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
>> >
>>
>
> One of the challenges of the developers conducting the risk-benefit
> analysis are that the developers are mostly focused on new features, but
> there are deployments of hive that are 5+ years old and people that rely on
> the features are not on the mailing list.
>
> For example I developed and use this frequently:
>
> https://community.hortonworks.com/articles/8861/apache-hive-
> groovy-udf-examples.html
>
> My career went away from hive for a while. I was quite surprised to find
> out the cli->beeline it was more or less decided not to port it. I learned
> of this the first time I was forced to work in a hive server only
> environment and it did not work.
>
> Now I have to go and spend time adding this back so I don't have to work
> around it not being there.
>
> What we should do continue/doing is making code that is modular we need to
> break hard dependencies like ThriftSerde or OrcSerde being "native" and
> having to be linked to the metastore move them out into proper submodules.
> There is too much code that only works for one implementation of a serde
> etc.
>
>
>

I would like a timeline to understand this. It sounds as if master is not
releasable currently, so already broken in a way. We make a branch and
aggreasively break it more?

Im not following what makes this branching policy makes adding features
faster or how it helps shed debt faster.


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

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