Re: Backward incompatible changes

Hello all - Just want to know how are things going with the 2.2 release. Has there been a candidate release build? In addition, what is the list of JIRA that has been included? is it same as the one we can run a query in for Hive JIRA ? like: project = HIVE AND issuetype in standardIssueTypes()

Re: Backward incompatible changes

We'll have to revise some TODOC2.2 labels in JIRA, as well as fix versions. -- Lefty On Fri, Mar 24, 2017 at 2:19 PM, Ashutosh Chauhan wrote: > Sounds good to me. I have created Fix versions 3.0 and 2.3 in jira. We can > use 2.3 for next release from branch-2. > > On Fri, Mar 24, 2017 at 10:46

Re: Backward incompatible changes

Sounds good to me. I have created Fix versions 3.0 and 2.3 in jira. We can use 2.3 for next release from branch-2. On Fri, Mar 24, 2017 at 10:46 AM, Owen O'Malley wrote: > All, > > I'm glad to see a plan to release master before the incompatible changes. > It will be great to have a release that

Re: Backward incompatible changes

All, I'm glad to see a plan to release master before the incompatible changes. It will be great to have a release that uses the separated out ORC code base. As I had previously discussed on list, I've been working on building a proposed 2.2 branch, which builds on 2.1.1 and cherry picks a bunch o

Re: Backward incompatible changes

So, I just pushed branch-2 from current tip. Now, lets get 2.2 release out as soon as possible. Thanks, Ashutosh On Thu, Mar 23, 2017 at 9:46 PM, Ashutosh Chauhan wrote: > Cutting a branch should not slow down a 2.2 release. If any thing, this > should help in achieving stabilization faster for

Re: Backward incompatible changes

Cutting a branch should not slow down a 2.2 release. If any thing, this should help in achieving stabilization faster for release since branch won't get any new potentially destabilizing changes but only patches to fix existing known issues. On Thu, Mar 23, 2017 at 8:22 AM, Eugene Koifman wrote:

Re: Backward incompatible changes

+1 to make a release first On 3/22/17, 2:06 PM, "Sergey Shelukhin" wrote: Hmm.. should we release these first, and then cut branch-2? Otherwise during the releases, the patches for 2.2/2.3 will need to go to 3 (4?) places (master, branch-2, branch-2.2, branch-2.3?). There’s no ru

Re: Backward incompatible changes

Hmm.. should we release these first, and then cut branch-2? Otherwise during the releases, the patches for 2.2/2.3 will need to go to 3 (4?) places (master, branch-2, branch-2.2, branch-2.3?). There’s no rush to cut the branch if everything in 2.2/2.3 has to go to 3.0 anyway. On 17/3/22, 13:53, "P

Re: Backward incompatible changes

I would like to work as the Release Manager if possible. As Owen points out, he is working on 2.2 and I will work on 2.3. Thanks. On Wed, Mar 22, 2017 at 1:32 PM, Ashutosh Chauhan wrote: > Unless there is more feedback, I plan to cut branch-2 in a day or two from > current master. As multiple pe

Re: Backward incompatible changes

Unless there is more feedback, I plan to cut branch-2 in a day or two from current master. As multiple people have suggested on this thread, we should do a 2.2 release soon. Currently there are 177 issues

Re: Backward incompatible changes

I hear what you are saying. Lets begin with 3 concerns: - How will we keep the community motivated on fixing both master and branch-2? Until we do a stable release from master, stable releases can come only from branch-2. If a contributor wants to see their fix reach to users on a stable line quic

Re: Backward incompatible changes

Hey Ashutosh, thanks for soliciting feedback on this. I like the idea you're proposing; maintaining compatibility and at the same time adding newer features to Hive consumes a lot of development time and effort. However, I think some users and companies have just started to use Hive 2.x branch as

Re: Backward incompatible changes

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 us

Re: Backward incompatible changes

Agreed. Infact we should utilize branch-2 for any stabilization efforts we intend to put in to make 2.2 release. Thanks, Ashutosh On Fri, Mar 3, 2017 at 3:52 PM, Sergey Shelukhin wrote: > Can we at least release 2.2 first? There’s massive amount of unreleased > code right now on master. > > On

Re: Backward incompatible changes

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 ti

Re: Backward incompatible changes

Releasability of trunk won't be impacted by this. e.g., If someone wants to do a release for Hive 3.0 as soon as we cut branch-2 that should not be an issue. We ofcourse will label it as alpha. After that doing more alpha or beta releases can go on as long as we as community wants to keep those qua

Re: Backward incompatible changes

Also i dont follow how we remove On Saturday, March 4, 2017, Edward Capriolo wrote: > > > On Fri, Mar 3, 2017 at 8:46 PM, Thejas Nair > 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

Re: Backward incompatible changes

On Fri, Mar 3, 2017 at 8:46 PM, Thejas Nair 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+ > Default+Auth

Re: Backward incompatible changes

I am in favor of leaning the codebase and removing some old features which could be breaking compatibility. This would also give us opportunity to remove some age old optimizations, configs, remove things we have already marked deprecated etc. Some of changes that we can potentially do is - Remo

Re: Backward incompatible changes

+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+Default+Authorization+-+Legacy+Mode . It is inherently insecure mode that nobo

Re: Backward incompatible changes

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 >

Re: Backward incompatible changes

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" wrote: >Hi all, > >Hive project has come a long way. With wide-spread adoption also comes >expectations. Expectation of being backward compatible and not breakin