Repository navigation
HIVE-30051: Improve HowToRelease with Maven Central verification script - #120
saihemanth-cloudera wants to merge 2 commits into
Conversation
zabetak
left a comment
zabetak
left a comment
There was a problem hiding this comment.
Many thanks for improving the release documentation @saihemanth-cloudera ! Left some small comments/questions.
| 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.) |
There was a problem hiding this comment.
- In terms of process maybe we should first create a PR with the changes, then wait for a green CI, and finally merge it.
- I don't know if anyone knows about gh-pages anymore so we can probably delete the last sentence.
| ### 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). | ||
|
|
There was a problem hiding this comment.
There seems to be overlap with step 8 in "Publishing" section. We don't need duplicate content.
|
|
||
| ### 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). |
There was a problem hiding this 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?
There was a problem hiding this comment.
Ack. I'm moving the script to stage repo instead of central.
| ./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. |
There was a problem hiding this 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.
| ./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. |
There was a problem hiding this 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.
| # 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 |
There was a problem hiding this 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.
There was a problem hiding this comment.
I think the new-only modules could be left for a future enhancement.
|
|
||
| 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). |
There was a problem hiding this comment.
As mentioned below it would be great if we could catch problems before publishing the artifacts to central. Is it possible?
There was a problem hiding this comment.
Addressed it in latest patchset.
Verify artifacts on Nexus staging before Central release, document intentional module removals, dedupe website steps, and update the RC vote template. Co-authored-by: Cursor <cursoragent@cursor.com>
This branch has not been deployed
2 participants
No description provided.