dannycjones commented on code in PR #3085: URL: https://github.com/apache/iceberg-rust/pull/3085#discussion_r3873644682
########## website/src/release.md: ########## @@ -602,6 +602,19 @@ On behalf of Apache Iceberg Community Example: <https://lists.apache.org/thread/oy77n55brvk72tnlb2bjzfs9nz3cfd0s> +### Merge changes from the release branch into main + +As the release branch evolves, changes will be added there that should be introduced to `main` branch too. +This is the case even for the first release on a branch, since every release includes `CHANGELOG.md` entry updates. + +Create a pull request that pulls back the changes from the release branch. +To prepare the pull request, +create a merge commit from the release branch into main, +run `make generate-public-api` and `./dev/release/dependencies.sh generate`, +and open the pull request with both changes. + +Once merged into `main`, `main` is then ready for future release branches being cut from it. Review Comment: This documents what I've done for 0.10.1, however I think this falls apart if we're doing a patch release for an older minor version. Ultimately, I'm wondering if we need a set of rules to say: if a change needs making to a release branch, it must first be made on `main` (where applicable) and a second PR must cherry-pick (or effectively cherry-pick) that change on to the release branch. Presumably we would need to do that for changelog? OR maybe changelog is one where we reverse backport it... Open to thoughts here. -- 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]
