The proposal to post the source and bin to the distribution sounds good to me. We can do the testing and release standalone-metastore 3.1 like to you suggested above.
On Tue, May 29, 2018 at 10:49 PM, Peter Vary <pv...@cloudera.com> wrote: > What do you think about adding a ne profile, which adds a possibility to > compile the code with one command, until we separate standalone metastore > to a new project? Like -Pitests, but -Pmetastore. So "mvn clean install > -Pmetastore,itests" will compile everything. > > Alan Gates <alanfga...@gmail.com> ezt írta (időpont: 2018. máj. 30., Sze > 0:42): > > > On Tue, May 29, 2018 at 3:29 PM Vihang Karajgaonkar <vih...@cloudera.com > > > > wrote: > > > > > How about cutting out a branch-3.0.1 and releasing 3.0.1 with the > pom.xml > > > fixed? My concern with above approach is we haven't tested > > > standalone-metastore when deployed independent of Hive. > > > > Actually, there is. The tarballs for source and bin are already out > > there. If I post them on the distribution site then they'll be easier to > > find. So we can test that now. And we can then do a 3.1 release of the > > metastore whenever we want, as long as it's before a 3.1 release of Hive. > > > > Alan. > > > > > > > So we don't know if > > > there is something is fundamentally broken in that mode and given that > we > > > don't know when 3.1 is going to be released it may remain in that state > > for > > > long time which is not good. I think may be a good approach now would > be > > to > > > test 3.0 standalone-metastore and fix any issues along with the pom.xml > > > changes and do a 3.0.1 release. What do you think? > > > > > > Thanks, > > > Vihang > > > > > > On Tue, May 29, 2018 at 1:57 PM, Alan Gates <alanfga...@gmail.com> > > wrote: > > > > > > > In the thread on releasing Hive 3.0 I wrote > > > > <quote> > > > > We should work on producing a standalone-metastore > > > > release in the same time frame so that the schema's, etc. match. I > can > > RM > > > > that unless someone else wants to. > > > > </quote> > > > > https://lists.apache.org/thread.html/307b281c3742fdf6aeb7fac > > > > 3ee74a98830400b67711755572de15b80@%3Cdev.hive.apache.org%3E > > > > > > > > My thinking was to produce a separate metastore release, like we do > for > > > > storage-api. However, I missed that I needed to do some work in > > > branch-3.0 > > > > to disconnect standalone-metastore from the pom before the release > (in > > > the > > > > same way that storage-api does). Thus when we released Hive 3.0 we > > also > > > > released the standalone-metastore. See > > > > https://search.maven.org/#search%7Cga%7C2%7Cg%3A%22org. > apache.hive%22 > > > So > > > > I can't release another version of standalone-metastore 3.0. Here is > > > what > > > > I propose we do: > > > > > > > > > > > > 1. Put the src and bin tarballs for standalone-metastore in Hive's > > > > distribution site. We have already voted on these as part of 3.0 > > > > release > > > > process. > > > > 2. Like storage-api, we keep the standalone-metastore linked in > the > > > pom > > > > in the master branch. This makes life easier for developers as > they > > > > produce new patches. > > > > 3. Also like storage-api, at some future point before we release > > Hive > > > > 3.1 I will: > > > > 1. Make a separate branch for standalone-metastore from > branch-3 > > > > 2. Release a standalone-metastore 3.1 from this new branch > > > > 3. Remove standalone-metastore from the list of sub-modules in > > > Hive's > > > > pom.xml > > > > 4. Make Hive depend on the released 3.1 version of the > > > > standalone-metastore. > > > > 4. For branch-3.0, I do not propose to do the same separation as > in > > > > branch-3, but we can make a different choice in the future if > there > > > is a > > > > reason to do so. > > > > > > > > Make sense? Thoughts? > > > > > > > > Alan. > > > > > > > > > >
