Hi Stamatis,
Thank you for initiating this very valuable discussion.
Regarding the first point, although we release two independent
binary packages for Hive and Metastore, the source code for both Hive and
Metastore remains in the same repository, and there may still be coupling
between their codebases. Therefore, if an issue arises in one binary package
and requires code changes, we typically rebuild both binary packages. So, in my
opinion, there isn't a good way at the moment to completely decouple the
release processes of these two binary packages.
Regarding the second point, the issue mainly revolves around
hive-storage-api. I noticed that the Hive community previously released the
hive-storage-api dependency independently [1], which addressed the dependency
problem for other binary packages like Metastore on hive-storage-api. However,
based on the current state of Hive, I don't think it's necessary for us to
continue releasing hive-storage-api separately. As Zhihua mentioned: "The
Metastore source build should be OK for the user once we publish the artifacts
to the Maven repository successfully." Of course, you can also resolve this
issue by setting up a temporary Maven repository during the RC phase before the
official Maven release, such as the Hive Maven repository for this RC1:
|
<repositories>
<repository>
<id>apache-releases</id>
<name>Apache Release Repository</name>
<url>https://repository.apache.org/content/repositories/orgapachehive-1140/</url>
</repository>
</repositories>
|
BTW, I believe we still need to further improve the Hive documentation, as well
as the Metastore README you mentioned, to provide guidance on how to build the
Metastore binary package.
Thanks,
Butao Zhang
---- Replied Message ----
| From | Zhihua Deng<den...@apache.org> |
| Date | 7/25/2025 08:31 |
| To | <dev@hive.apache.org> |
| Subject | Re: [DISCUSS] Hive 4.1.0 release issues |
Hi Stamatis,
The Metastore source build should be OK for the user once we publish the
artifacts to the Maven repository successfully.
For the naming conventions, mainly due to HIVE-29062 which chooses to follow
the old pattern the metastore 3.0.0.
[1] https://issues.apache.org/jira/browse/HIVE-29062
[2]
https://dist.apache.org/repos/dist/release/hive/hive-standalone-metastore-3.0.0/
Regards,
Zhihua
On 2025/07/24 16:44:42 Stamatis Zampetakis wrote:
Hello,
During the verification of RC1 I spotted some issues that I would like
to bring up for discussion.
I don't want to clutter the main vote thread thus I opted to start a
separate thread.
The first point is the common vote thread for both Hive and Metastore.
If we plan to release independent sources and binaries for the "two"
projects it makes more sense to hold separate votes. Currently, the
number of checks that we need to perform as a community is rather high
and takes a significant amount of time to test everything. Moreover,
from the moment that one issue pops-up, even if it is isolated in one
archive, it can stop the entire RC process; it is not possible to say
+1 here, and -1 there.
Secondly, I tried to build the standalone metastore from the source
archive (hive-standalone-metastore-4.1.0-src.tar.gz) but the built
fails cause it has dependencies to hive (e.g., hive-storage-api). If
we don't build Hive before, the
hive-standalone-metastore-4.1.0-src.tar.gz is unusable so I don't see
the benefit in making this archive part of the release process.
Assuming that we can build the hive-standalone-metastore-4.1.0-bin
from apache-hive-4.1.0-src.tar.gz, I would suggest to drop the
hive-standalone-metastore-4.1.0-src.tar.gz at least for now. A more
subtle issue with the standalone source archive is that it doesn't
contain a README and there are no instructions on how to build the
binaries.
More generally, the build instructions for the project are not fully
up-to-date thus I logged HIVE-29102 and HIVE-29103 for tracking
efforts towards this direction.
Another minor issue is the naming conventions that we use for Hive and
Metastore. The metastore archives do not contain the "apache-" prefix.
Although this is not a hard requirement it is a good practice to
protect our (ASF) product branding. Interestingly once we unarchive
the content the apache prefix is present in the extracted directories.
Best,
Stamatis
