voonhous commented on code in PR #19642: URL: https://github.com/apache/hudi/pull/19642#discussion_r3795447133
########## release/release_guide.md: ########## @@ -290,6 +290,31 @@ Here is how to go about a bug fix release. - Go to apache/hudi repo locally and pull this branch. Here after you can work on this branch and push to origin when need be. - Do not forget to set the env variables from above section. +## hudi-trino Trino pin-back + +On master hudi-trino tracks `trinodb/trino` master at the commit in `trino.sha`, whose `trino.version` is a +`-SNAPSHOT` that resolves from nowhere but a local build. A release must depend on a released Trino, and the pin-back +must land on the release branch before the source release is generated (see "Build a release candidate", the Generate +Source Release step) -- otherwise the voted tarball ships a `-SNAPSHOT` Trino pin that cannot be built from Central. + +1. Wait for the latest released Trino `NNN` to be available on Maven Central. +2. In a `trinodb/trino` checkout, find the tagged commit: `TAG_SHA=$(git rev-list -n1 NNN)`. +3. If the pin is behind the tag, advance master's pin to `TAG_SHA` first by dispatching the + `Hudi Trino SPI Compatibility` workflow with `trino_ref=NNN` (it then verifies and pins exactly that tag rather + than master HEAD) and merging the pin PR a committer opens from the pushed `bot/trino-pin` branch. If the pin is ahead of the tag, enumerate the adaptations that would be lost with + `git log NNN..<pin> -- core/trino-spi lib/trino-filesystem lib/trino-filesystem-manager lib/trino-hdfs` Review Comment: Fixed: step 3 now lists the same five paths as the gate, including lib/trino-memory-context. ########## release/release_guide.md: ########## @@ -290,6 +290,31 @@ Here is how to go about a bug fix release. - Go to apache/hudi repo locally and pull this branch. Here after you can work on this branch and push to origin when need be. - Do not forget to set the env variables from above section. +## hudi-trino Trino pin-back + +On master hudi-trino tracks `trinodb/trino` master at the commit in `trino.sha`, whose `trino.version` is a +`-SNAPSHOT` that resolves from nowhere but a local build. A release must depend on a released Trino, and the pin-back +must land on the release branch before the source release is generated (see "Build a release candidate", the Generate +Source Release step) -- otherwise the voted tarball ships a `-SNAPSHOT` Trino pin that cannot be built from Central. + +1. Wait for the latest released Trino `NNN` to be available on Maven Central. +2. In a `trinodb/trino` checkout, find the tagged commit: `TAG_SHA=$(git rev-list -n1 NNN)`. +3. If the pin is behind the tag, advance master's pin to `TAG_SHA` first by dispatching the + `Hudi Trino SPI Compatibility` workflow with `trino_ref=NNN` (it then verifies and pins exactly that tag rather + than master HEAD) and merging the pin PR a committer opens from the pushed `bot/trino-pin` branch. If the pin is ahead of the tag, enumerate the adaptations that would be lost with + `git log NNN..<pin> -- core/trino-spi lib/trino-filesystem lib/trino-filesystem-manager lib/trino-hdfs` Review Comment: Fixed: step 3 now lists the same five paths as the gate, including `lib/trino-memory-context`. -- 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]
