Skip to content

chore(release): v2.2.0 - #919

Merged
google-oss-prow[bot] merged 1 commit into
mainfrom
release-v2.2.0
Aug 5, 2026
Merged

chore(release): v2.2.0#919
google-oss-prow[bot] merged 1 commit into
mainfrom
release-v2.2.0

Conversation

@ederign

@ederign ederign commented Aug 5, 2026

Copy link
Copy Markdown
Member

What

Version bump for the 2.2.0 release, per RELEASE.md.

File From To
kale/__init__.py 2.1.0 2.2.0
labextension/package.json 2.1.0 2.2.0
CHANGELOG/CHANGELOG-2.2.md — new (91 lines)

This must merge before the release workflow can run. The workflow has no version input — release.yml:32-37 reads __version__ off whatever branch you select, so running it against main today would just re-release 2.1.0.

Why main was still on 2.1.0

main hadn't moved since "Bump dev version to 2.1.0" (#769) in April. v2.1.1 was cut from the release-2.1 branch, and its dev-version bumps (#819, #827) landed there rather than on main.

Nothing is stranded on release-2.1 — its only functional commit, e8e90cc, is the backport of #823, already on main as 60e256e. So this release covers the 41 commits on main since v2.1.0, including the Configure-dialog consolidation (#908), the HTML-report toggle (#889), auto-promoted output artifacts (#874), and the dependency sweep in #918.

A note on the changelog

The changelog here was generated scoped:

git-cliff v2.1.0..HEAD --tag v2.2.0 -o CHANGELOG/CHANGELOG-2.2.md

not with the bare git-cliff --output CHANGELOG/CHANGELOG-$MAJOR.$MINOR.md that make release runs. With no range argument, git-cliff emits the project's entire history — 2622 lines, 83 KB, every tag back to 2.0.0a1 — into a file named for one minor version, with the 2.2.0 entries under an ## [unreleased] heading because the tag doesn't exist yet.

That matters because github-release cats the file straight into the release body, so the v2.2.0 notes would have been 83 KB of full project history titled "unreleased". Scoped output is 91 lines under a proper ## [2.2.0] - 2026-08-05.

The make release target should probably pass the range itself. Left alone here to keep this PR to the version bump — happy to send that as a follow-up.

Testing

Ran the release workflow's own build steps locally:

  • make check-versions → 2.2.0 (Python) == 2.2.0 (npm)
  • SKIP_JUPYTER_BUILDER=1 uv sync --all-extras --frozen clean, and CI=true jlpm install --immutable still clean after the bump (both are what the release build job does)
  • make verify: ruff check, ruff format --check (58 files), stylelint, prettier, eslint, 270 backend tests, labextension jest suite
  • jlpm build:prod → make build produces kubeflow_kale-2.2.0-py3-none-any.whl + .tar.gz; twine check PASSED on both
  • fresh-venv install of the wheel, mirroring the test-wheels job: __version__ == "2.2.0" asserts, kale --help exits 0

After this merges

Actions → Release → Run workflow, branch main:

  1. target = dry-run — full build + wheel smoke tests, no tag, no publish
  2. target = testpypi — also pushes the v2.2.0 tag, creates the GitHub release, and opens the 2.2.1a1 bump PR (create-tag, github-release and bump-dev-version all gate on target != 'dry-run', not on PyPI). Validate with: 
    pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ kubeflow-kale==2.2.0
  3. target = testpypi+pypi — production PyPI, gated on the production environment's required reviewers

Then git checkout -b release-2.2 main && git push origin release-2.2, matching release-2.0 / release-2.1.

Worth merging the auto-generated 2.2.1a1 bump PR promptly — its 2.1.x equivalent (#827) going to release-2.1 instead of main is exactly why main sat at 2.1.0 for four months.

🤖 Generated with Claude Code

@ederign @claude
chore(release): v2.2.0
8f94a3b 
Bumps the version for the 2.2.0 release, per RELEASE.md. The release
workflow has no version input - it reads __version__ off the branch you
select (.github/workflows/release.yml:32) - so this has to land on main
before Actions -> Release can cut 2.2.0.

  kale/__init__.py           2.1.0 -> 2.2.0
  labextension/package.json  2.1.0 -> 2.2.0
  CHANGELOG/CHANGELOG-2.2.md new

main has been sitting at 2.1.0 since "Bump dev version to 2.1.0" (#769)
in April. v2.1.1 was cut from the release-2.1 branch and its dev-version
bumps (#819, #827) landed there rather than on main, which is why main
never advanced. Nothing is stranded on release-2.1: its only functional
commit, e8e90cc, is the backport of #823, already on main as 60e256e.
This release therefore covers the 41 commits on main since v2.1.0.

The changelog is scoped to v2.1.0..HEAD and tagged v2.2.0:

  git-cliff v2.1.0..HEAD --tag v2.2.0 -o CHANGELOG/CHANGELOG-2.2.md

rather than the bare `git-cliff --output CHANGELOG/CHANGELOG-$MAJOR.$MINOR.md`
that `make release` runs. With no range argument git-cliff emits the
project's entire history - 2622 lines, 83KB, every tag back to 2.0.0a1 -
into a file named for a single minor version, with the 2.2.0 entries
under a "[unreleased]" heading because the tag doesn't exist yet. The
github-release job cats that file straight into the release body
(release.yml:230-246), so the v2.2.0 notes would have been 83KB of full
project history titled "unreleased". Scoped output is 91 lines under a
proper "[2.2.0] - 2026-08-05" heading. The Makefile target should
probably pass the range itself; left alone here to keep this PR to the
version bump.

Verified locally against the release workflow's own build steps:
- `make check-versions`: 2.2.0 (Python) == 2.2.0 (npm)
- `SKIP_JUPYTER_BUILDER=1 uv sync --all-extras --frozen` clean, and
  `CI=true jlpm install --immutable` still clean after the bump
- `make verify`: ruff check, ruff format --check (58 files), stylelint,
  prettier, eslint, 270 backend tests, labextension jest suite
- `jlpm build:prod` then `make build` produce kubeflow_kale-2.2.0-py3-none-any.whl
  and .tar.gz; `twine check` PASSED on both
- fresh-venv install of the wheel (mirrors the test-wheels job) asserts
  `__version__ == "2.2.0"` and `kale --help` exits 0

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Eder Ignatowicz <ignatowicz@gmail.com>
@ederign ederign mentioned this pull request Aug 5, 2026
Merged
@google-oss-prow google-oss-prow Bot added the lgtm label Aug 5, 2026
@jesuino

jesuino commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

/approve

@google-oss-prow

google-oss-prow Bot commented Aug 5, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jesuino

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@google-oss-prow
google-oss-prow Bot merged commit 0ad6f2b into main Aug 5, 2026
14 checks passed
google-oss-prow Bot pushed a commit that referenced this pull request Aug 5, 2026
@ederign @claude
fix(release): scope git-cliff to the X.Y line and tag the new section (…
315215b 
…#920)

`make release VERSION=X.Y.Z` ran git-cliff with no revision range and no
--tag:

    git-cliff --output CHANGELOG/CHANGELOG-$MAJOR.$MINOR.md

Both omissions matter, because the github-release job cats that file
straight into the GitHub release body (.github/workflows/release.yml:230-246):

- No range means git-cliff emits the project's entire history. Preparing
  2.2.0 produced 2622 lines / 83KB covering every tag back to v2.0.0a1,
  in a file named for a single minor version.
- No --tag means the new entries land under an "[unreleased]" heading,
  since the version's tag doesn't exist yet at bump time.

So the v2.2.0 release notes would have been 83KB of full project history
titled "unreleased". Nobody hit this before because CHANGELOG/ holds only
.gitkeep - v2.1.0 and v2.1.1 both shipped with git-cliff absent, falling
back to generate_release_notes.

Scope the range to the X.Y line the version belongs to, starting from the
newest reachable tag outside that line:

    BASE=$(git tag --list 'v[0-9]*' --merged HEAD --sort=-v:refname \
            | grep -v "^v$MAJOR\.$MINOR\." | head -1)
    git-cliff "$BASE..HEAD" --tag v$(VERSION) --output $OUT

Two details worth keeping:

- Excluding the current X.Y line, rather than just taking the previous
  tag, is what makes CHANGELOG-X.Y.md accumulate. Cutting 2.2.1 after
  2.2.0 resolves BASE to v2.1.0, so the file keeps both sections. A
  `git describe --abbrev=0` would resolve to v2.2.0 and silently drop
  2.2.0's entries from its own changelog on every patch release.
- `--merged HEAD` keeps tags cut on other release branches out of the
  range. v2.1.1 exists but was tagged on release-2.1, so preparing 2.2.0
  from main correctly bases on v2.1.0.

Also replace the `command -v git-cliff && { ... } || printf` construct
with an explicit if/else. In the old form any failure inside the braces -
now including a bad range - printed "git-cliff not found, skipping",
which would have been actively misleading.

Falls back to full history with --tag when no base tag is reachable, for
the first release on a fresh history.

Verified: on main, `make release VERSION=2.2.0` now emits
CHANGELOG-2.2.md as "v2.1.0..HEAD, tagged v2.2.0" - 91 lines under a
"## [2.2.0] - 2026-08-05" heading, byte-identical to the changelog
hand-generated for #919. Simulated a v2.2.0 tag and confirmed 2.2.1
still bases on v2.1.0.

Signed-off-by: Eder Ignatowicz <ignatowicz@gmail.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
@ederign
ederign deleted the release-v2.2.0 branch August 5, 2026 14:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@StefanoFioravanzo StefanoFioravanzo Awaiting requested review from StefanoFioravanzo
1 more reviewer
@jesuino jesuino jesuino approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@jesuino jesuino

Labels

approved lgtm size/M

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@ederign @jesuino