Skip to content

Spell out the empty version suffix for the SVN provider build - #71247

Open
potiuk wants to merge 1 commit into
apache:mainfrom
potiuk:doc-explicit-empty-version-suffix
Open

Spell out the empty version suffix for the SVN provider build#71247
potiuk wants to merge 1 commit into
apache:mainfrom
potiuk:doc-explicit-empty-version-suffix

Conversation

@potiuk

@potiuk potiuk commented Aug 6, 2026

Copy link
Copy Markdown
Member

The release doc builds the SVN wave with:

breeze release-management prepare-provider-distributions --include-removed-providers --distribution-format both

No --version-suffix. The prose a few paragraphs earlier does say the packages "should keep the final version number without the rc suffix", but an omitted flag reads as this flag does not matter here rather than it must be empty — especially next to the PyPI section, which passes --version-suffix rcN for what looks like the same command.

Get it wrong and the SVN wave is built as apache_airflow_providers_airbyte-6.0.1rc2-py3-none-any.whl instead of ...-6.0.1-.... Nothing complains at the time. It surfaces at the end of the release, when promoting the RC is supposed to be a plain svn mv and instead needs a full rebuild, re-sign and re-commit of the whole wave. That happened during the 2026-08-06 wave.

This passes --version-suffix "" explicitly at all three build sites — the RC build, the few-packages variant, and the reproducible-build verification (which has to match how the artifacts were actually produced, or the check compares against differently-named files) — and adds a note stating why the empty value is the point, and how the SVN and PyPI builds differ.

Docs only; no behaviour change.

Was generative AI tooling used to co-author this PR?
  • Yes — Claude Opus 5 (1M context)

Generated-by: Claude Opus 5 (1M context) following the guidelines

The command omitted --version-suffix entirely, which reads as 'the flag does
not matter here' rather than 'it must be empty'. Building the SVN wave with an
rc suffix produces filenames that cannot be promoted by renaming, and the
mistake only surfaces at the end of the release when the promotion is attempted.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant