You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by Owen O'Malley <om...@apache.org> on 2017/01/01 18:19:23 UTC
[DISCUSS] Separate release of storage-api
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. Once HIVE-15419 is committed,
I'd like to cut a branch (eg storage-branch-2.2) and make a release
candidate (eg. storage-release-2.2.0rc0).
Any concerns?
Thanks,
Owen
Re: [DISCUSS] Separate release of storage-api
Posted by Owen O'Malley <om...@apache.org>.
On Tue, Jan 3, 2017 at 1:51 PM, Sergey Shelukhin <se...@hortonworks.com>
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 master branch and related
development branches would use a snapshot release that was built as part of
the hive build. See the pull request on HIVE-15419 for what it will look
like.
If there are unreleased
> storage-api changes when Hive is being released that are needed for the
> release, they’d be released all together just before the Hive release, if
> needed.
>
The two major drivers of storage-api releases are going to be wanting to
release either ORC or Hive.
.. Owen
>
> On 17/1/1, 10:19, "Owen O'Malley" <om...@apache.org> wrote:
>
> >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+Propo
> >sal
> >and the patch for HIVE-15419 is pretty close. Once HIVE-15419 is
> >committed,
> >I'd like to cut a branch (eg storage-branch-2.2) and make a release
> >candidate (eg. storage-release-2.2.0rc0).
> >
> >Any concerns?
> >
> >Thanks,
> > Owen
>
>
Re: [DISCUSS] Separate release of storage-api
Posted by Sergey Shelukhin <se...@hortonworks.com>.
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, they’d be released all together just before the Hive release, if
needed.
On 17/1/1, 10:19, "Owen O'Malley" <om...@apache.org> wrote:
>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+Propo
>sal
>and the patch for HIVE-15419 is pretty close. Once HIVE-15419 is
>committed,
>I'd like to cut a branch (eg storage-branch-2.2) and make a release
>candidate (eg. storage-release-2.2.0rc0).
>
>Any concerns?
>
>Thanks,
> Owen
Re: [DISCUSS] Separate release of storage-api
Posted by Thejas Nair <th...@gmail.com>.
+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 <al...@gmail.com> 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 it out
> here to be clear we're choosing this rather than there being questions next
> time we release something on what the number should be.
>
> Alan.
>
> 1. Support for my statement that this is the only viable option:
> a) Tying together the version numbers of Hive proper and the storage API
> undoes exactly the independence we're trying to enable here.
> b) Lefty's concern that Sergey's solution will make a hash of the JIRAs is
> a deal breaker for that one. It also will be harder to truly separate
> these in the future if Sergio is correct and this eventually evolves into a
> proper sub-project or separate project.
> c) Other projects with this same issue let their version numbers move
> independently (e.g. datanucleus)
> d) Our pom files will give us the mapping of how the versions fit together.
>
>
> > On Jan 1, 2017, at 10:19 AM, Owen O'Malley <om...@apache.org> wrote:
> >
> > 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. Once HIVE-15419 is
> committed,
> > I'd like to cut a branch (eg storage-branch-2.2) and make a release
> > candidate (eg. storage-release-2.2.0rc0).
> >
> > Any concerns?
> >
> > Thanks,
> > Owen
>
>
Re: [DISCUSS] Separate release of storage-api
Posted by Owen O'Malley <om...@apache.org>.
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 <al...@gmail.com> 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 it out
> here to be clear we're choosing this rather than there being questions next
> time we release something on what the number should be.
>
> Alan.
>
> 1. Support for my statement that this is the only viable option:
> a) Tying together the version numbers of Hive proper and the storage API
> undoes exactly the independence we're trying to enable here.
> b) Lefty's concern that Sergey's solution will make a hash of the JIRAs is
> a deal breaker for that one. It also will be harder to truly separate
> these in the future if Sergio is correct and this eventually evolves into a
> proper sub-project or separate project.
> c) Other projects with this same issue let their version numbers move
> independently (e.g. datanucleus)
> d) Our pom files will give us the mapping of how the versions fit together.
>
>
> > On Jan 1, 2017, at 10:19 AM, Owen O'Malley <om...@apache.org> wrote:
> >
> > 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. Once HIVE-15419 is
> committed,
> > I'd like to cut a branch (eg storage-branch-2.2) and make a release
> > candidate (eg. storage-release-2.2.0rc0).
> >
> > Any concerns?
> >
> > Thanks,
> > Owen
>
>
Re: [DISCUSS] Separate release of storage-api
Posted by Alan Gates <al...@gmail.com>.
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 it out here to be clear we're choosing this rather than there being questions next time we release something on what the number should be.
Alan.
1. Support for my statement that this is the only viable option:
a) Tying together the version numbers of Hive proper and the storage API undoes exactly the independence we're trying to enable here.
b) Lefty's concern that Sergey's solution will make a hash of the JIRAs is a deal breaker for that one. It also will be harder to truly separate these in the future if Sergio is correct and this eventually evolves into a proper sub-project or separate project.
c) Other projects with this same issue let their version numbers move independently (e.g. datanucleus)
d) Our pom files will give us the mapping of how the versions fit together.
> On Jan 1, 2017, at 10:19 AM, Owen O'Malley <om...@apache.org> wrote:
>
> 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. Once HIVE-15419 is committed,
> I'd like to cut a branch (eg storage-branch-2.2) and make a release
> candidate (eg. storage-release-2.2.0rc0).
>
> Any concerns?
>
> Thanks,
> Owen