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 <omal...@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
