zabetak commented on code in PR #120: URL: https://github.com/apache/hive-site/pull/120#discussion_r4012918849
########## content/community/resources/howtorelease.md: ########## @@ -476,11 +481,12 @@ git clone https://github.com/apache/hive-site.git ./content/docs/javadocs.md: * [Hive 1.2.0 Javadocs][r1.2.0] ./content/docs/javadocs.md:[r1.2.0]: /javadocs/r1.2.0/api/index.html ./config.toml: version = "1.2.0" (under [params.release]) +./themes/hive/layouts/partials/release-banner.html: update homepage banner text for the new version ``` As you can see, you will need a release note link for this release as created previously for this section. -9. Push your changes to the <https://github.com/apache/hive-site/tree/gh-pages> branch, and you can preview the results at <https://apache.github.io/hive-site/>. If everything is ok, then you can push your changes to <https://github.com/apache/hive-site/tree/main> branch and see the results at <https://hive.apache.org/> site. +9. Merge your `hive-site` changes to the <https://github.com/apache/hive-site/tree/main> branch. The site is built and deployed automatically via GitHub Actions to the `asf-site` branch and published at <https://hive.apache.org/>. (The old `gh-pages` preview flow is no longer used.) Review Comment: 1. In terms of process maybe we should first create a PR with the changes, then wait for a green CI, and finally merge it. 2. I don't know if anyone knows about gh-pages anymore so we can probably delete the last sentence. ########## content/community/resources/howtorelease.md: ########## @@ -528,6 +534,49 @@ Regards, The Apache Hive Team ``` +### Verify Maven Central artifacts + +After Nexus release (and again before the `[ANNOUNCE]` mail), confirm that Maven Central has the modules users expect. Maintenance releases should publish the same `org.apache.hive` modules as the previous GA in that line (handlers, Iceberg, JDBC, and so on). + +Download and run the checker script from this repository (or copy it from your `hive-site` clone): + +``` +curl -O https://hive.apache.org/scripts/verify-maven-central-release.sh +chmod +x verify-maven-central-release.sh +./verify-maven-central-release.sh 4.2.0 4.2.1 +``` + +Replace versions with the previous GA and the release you just shipped. The script discovers `org.apache.hive` artifacts from Maven Search for the previous version and checks that each **JAR** artifact is also published for the new version (POM-only aggregator modules are skipped). It exits with a non-zero status if anything is missing. + +You can also run it from a local `hive-site` checkout: + +``` +./static/scripts/verify-maven-central-release.sh <previous-version> <new-version> +``` + +Include a note in the RC vote thread that voters may run this check after artifacts are staged. + +### Republishing missing Maven modules + +If verification finds gaps (as in [HIVE-30010](https://issues.apache.org/jira/browse/HIVE-30010)): + +1. Check out the release tag, for example `rel/release-X.Y.Z`. +2. Identify modules published for the previous GA but missing for the new version (the script above, or compare Central manually). +3. Build only the missing modules: `mvn install -pl <module-list> -am -DskipTests`. **Iceberg modules require `-PerrorProne`** (Immutables annotation processing in `iceberg/pom.xml`). +4. Deploy only those modules: `mvn deploy -pl <module-list> -Papache-release -DskipTests -Dmaven.javadoc.skip=true` (do not use `-am` on deploy, to avoid republishing artifacts already on Central). +5. Close and release the new staging repository in Nexus, then re-run the verification script. + +Keep release helper scripts **outside** the `hive` source tree (for example next to your clone). Scripts in the Hive repo root without Apache license headers will fail `mvn apache-rat:check`. + +### Release notes for website updates + +When updating `hive-site` for a new version, remember: + +* `content/general/downloads.md` — news entry and JIRA changelog link (look up the Fix Version id in JIRA). +* `content/docs/javadocs.md` — link to `/javadocs/rX.Y.Z/api/index.html` on the ASF javadoc SVN path. +* `config.toml` — `[params.release].version` and the `announcements` anchor under `[params.navbar]`. +* `themes/hive/layouts/partials/release-banner.html` — homepage “new release” banner text (easy to forget after `downloads.md` is updated). + Review Comment: There seems to be overlap with step 8 in "Publishing" section. We don't need duplicate content. ########## content/community/resources/howtorelease.md: ########## @@ -528,6 +534,49 @@ Regards, The Apache Hive Team ``` +### Verify Maven Central artifacts + +After Nexus release (and again before the `[ANNOUNCE]` mail), confirm that Maven Central has the modules users expect. Maintenance releases should publish the same `org.apache.hive` modules as the previous GA in that line (handlers, Iceberg, JDBC, and so on). Review Comment: In fact it would be better to catch this kind of problems before we push to central. Central is "almost" immutable so if we screw up there it might be very difficult to fix it. The main reason for having a staging repo is to inspect and find problems before publishing to central. Can we modify the instructions/code to do the necessary work on Nexus? ########## content/community/resources/howtorelease.md: ########## @@ -528,6 +534,49 @@ Regards, The Apache Hive Team ``` +### Verify Maven Central artifacts + +After Nexus release (and again before the `[ANNOUNCE]` mail), confirm that Maven Central has the modules users expect. Maintenance releases should publish the same `org.apache.hive` modules as the previous GA in that line (handlers, Iceberg, JDBC, and so on). + +Download and run the checker script from this repository (or copy it from your `hive-site` clone): + +``` +curl -O https://hive.apache.org/scripts/verify-maven-central-release.sh +chmod +x verify-maven-central-release.sh +./verify-maven-central-release.sh 4.2.0 4.2.1 +``` + +Replace versions with the previous GA and the release you just shipped. The script discovers `org.apache.hive` artifacts from Maven Search for the previous version and checks that each **JAR** artifact is also published for the new version (POM-only aggregator modules are skipped). It exits with a non-zero status if anything is missing. + +You can also run it from a local `hive-site` checkout: + +``` +./static/scripts/verify-maven-central-release.sh <previous-version> <new-version> +``` + +Include a note in the RC vote thread that voters may run this check after artifacts are staged. Review Comment: This statement does not add much value here. We can modify directly the VOTE email template telling people that this verification step is available. ########## content/community/resources/howtorelease.md: ########## @@ -299,6 +299,11 @@ svn commit -m "Hive X.Y.Z release" ``` % mvn deploy -Papache-release -DskipTests -Dmaven.javadoc.skip=true ``` + +Run a **full** `mvn deploy` from the release tag for the whole reactor. Do not skip handler or Iceberg modules with `-pl` exclusions during the initial release deploy; a partial deploy can leave artifacts off Maven Central while the vote still passes (see [HIVE-30010](https://issues.apache.org/jira/browse/HIVE-30010)). + +After you close and release the staging repository in Nexus, verify Maven Central (see [Verify Maven Central artifacts](#verify-maven-central-artifacts) below). Review Comment: As mentioned below it would be great if we could catch problems before publishing the artifacts to central. Is it possible? ########## static/scripts/verify-maven-central-release.sh: ########## @@ -0,0 +1,165 @@ +#!/usr/bin/env bash +# +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to you under the Apache License, Version 2.0 +# (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +# Verify that Maven Central has the same org.apache.hive artifacts for a new +# release as for the previous release in the line (maintenance release check). +# +# Usage: +# ./verify-maven-central-release.sh <previous-version> <new-version> +# +# Example (after publishing 4.2.1): +# ./verify-maven-central-release.sh 4.2.0 4.2.1 Review Comment: I tried the script locally and I like the output. Not sure how it deals with new modules that may appear in new releases; I guess we can leave that for future enhancement. ########## content/community/resources/howtorelease.md: ########## @@ -528,6 +534,49 @@ Regards, The Apache Hive Team ``` +### Verify Maven Central artifacts + +After Nexus release (and again before the `[ANNOUNCE]` mail), confirm that Maven Central has the modules users expect. Maintenance releases should publish the same `org.apache.hive` modules as the previous GA in that line (handlers, Iceberg, JDBC, and so on). + +Download and run the checker script from this repository (or copy it from your `hive-site` clone): + +``` +curl -O https://hive.apache.org/scripts/verify-maven-central-release.sh +chmod +x verify-maven-central-release.sh +./verify-maven-central-release.sh 4.2.0 4.2.1 +``` + +Replace versions with the previous GA and the release you just shipped. The script discovers `org.apache.hive` artifacts from Maven Search for the previous version and checks that each **JAR** artifact is also published for the new version (POM-only aggregator modules are skipped). It exits with a non-zero status if anything is missing. Review Comment: Also worth mentioning that in some cases discrepancies may be ok. For example, in the next release the Druid module will no longer be there so this verification step will fail for sure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
