+1
I agree that using an independent version number for this release is the
better option.
Regarding the mapping, I see it like a dependency on a third party library.
Its based on what is in the pom.xml .
On Wed, Jan 11, 2017 at 9:36 AM, Alan Gates wrote:
> 90% of the discussion on the previous
There was also the wiki page that I put together that was discusses on jira.
proposal:
https://cwiki.apache.org/confluence/display/Hive/Storage+API+Release+Proposal
discussion on jira: https://issues.apache.org/jira/browse/HIVE-15419
.. Owen
On Wed, Jan 11, 2017 at 9:36 AM, Alan Gates wrote:
>
90% of the discussion on the previous thread was on version numbering, which
never came to a conclusion. Based on your RC candidate I assume you chose the
separate version numbering, but starting from the same 2.2.0 base number.
I agree this is the only viable option[1], but I wanted to point i
On Tue, Jan 3, 2017 at 1:51 PM, Sergey Shelukhin
wrote:
> Would it simplify the cross-project commit process if we actually always
> depended on the snapshot on master/etc., and only switched to a particular
> version of storage-api in release branches?
That was the intent in my proposal. The m
Would it simplify the cross-project commit process if we actually always
depended on the snapshot on master/etc., and only switched to a particular
version of storage-api in release branches? If there are unreleased
storage-api changes when Hive is being released that are needed for the
release, th
Hi all,
As we discussed back in
https://mid.mail-archive.com/dev@hive.apache.org/msg121112.html . I'd like
to make a release of storage-api. I've written up a proposal at
https://cwiki.apache.org/confluence/display/Hive/Storage+API+Release+Proposal
and the patch for HIVE-15419 is pretty close. O
