+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 <alanfga...@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 <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 > >
