The way it helps shedding debt is because dev can now do refactoring without fear of breaking some rarely used features. The way that helps for adding feature faster is since codebase is lean and easier to reason about its much easier to add new features.
More importantly though, it also helps users because we are setting the expectation from dev community. They can expect that future releases of 2.x to be backward compatible. At the same time whenever they decide to upgrade they only need to test their application once against 3.x as oppose to continuous breakage of one form or another if we continue to make incompatible changes in master without branching for 2.x Thanks, Ashutosh On Sat, Mar 4, 2017 at 10:19 AM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > Also i dont follow how we remove > > On Saturday, March 4, 2017, Edward Capriolo <edlinuxg...@gmail.com> wrote: > > > > > > > On Fri, Mar 3, 2017 at 8:46 PM, Thejas Nair <thejas.n...@gmail.com > > <javascript:_e(%7B%7D,'cvml','thejas.n...@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 <hashut...@apache.org > >> <javascript:_e(%7B%7D,'cvml','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 > >> > > >> > > > > 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. >
