wip

Author: roycaihw

kubernetes/base

@@ -40,7 +40,8 @@
 #   - CHANGELOG: latest snapshot becomes the release, create a new snapshot
 #     section that reflect the master branch state
 #   - README: add the release to README
-#   - an extra PR to update CHANGELOG and README in master
+#   - an extra PR to update CHANGELOG and README in master in sync with this new
+#     release
 #
 # Difference between 1&2: API change release notes
 #
@@ -52,6 +53,9 @@
 #   - python base diff: https://github.com/kubernetes-client/python-base/compare/commit1..commit2
 #   - Kubernetes changelog, e.g. https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md
 # - add debug log
+# - add a sentence about "changes since {last release}". In most cases our
+#   releases should be sequential. This script (the workflow above) is based on
+#   this assumption, and we should make the release note clear about that.
 #
 # Usage:
 
@@ -92,6 +96,9 @@ util::changelog::update_release_api_version $CLIENT_VERSION $old_client_version
 # don't need to collect release notes in release-1.18, because any API
 # change in 1.18.x (x > 17) must be a cherrypick that is already included in
 # release-1.19.
+# TODO(roycaihw): not all Kubernetes API changes modify the OpenAPI spec.
+# Download the patch and skip if the spec is not modified. Also we want want to
+# look at other k/k sections like "deprecation"
 release_notes=$(util::kube_changelog::get_api_changelog "$KUBERNETES_BRANCH" "$old_k8s_api_version")
 if [[ -n "$release_notes" ]]; then
   util::changelog::write_changelog v$CLIENT_VERSION "### API Change" "$release_notes"