Skip to content

feat(release): cut a release on every merge to main#6

Merged
xergioalex merged 1 commit intomainfrom
chore/always-release
May 2, 2026
Merged

feat(release): cut a release on every merge to main#6
xergioalex merged 1 commit intomainfrom
chore/always-release

Conversation

@xergioalex
Copy link
Copy Markdown
Member

Summary

Switches the release model so every merge to main ships at least a PATCH release, regardless of whether the commits follow conventional-commit prefixes. Lowers the cognitive load on contributors — no more "I merged but nothing got released" surprise.

What changes

pyproject.toml::[tool.semantic_release.commit_parser_options]:

  • default_bump_level from 01

Behavior matrix:

Commit prefix Result
feat: MINOR (e.g. 1.0.1 → 1.1.0)
fix: / perf: PATCH (e.g. 1.0.1 → 1.0.2)
feat!: or BREAKING CHANGE: body MAJOR
chore: / docs: / refactor: / no prefix at all PATCH (was: no release)

Conventional-commit prefixes are still honored — they let you upgrade from PATCH to MINOR/MAJOR. They are just no longer required.

AGENTS.md Rule 15 was rewritten to reflect the new policy.

Trade-off

More frequent PyPI releases. Each one is small. Acceptable for the simpler contributor experience.

How this validates

After this PR is merged, the very next PR (any PR) will cut a release. We will see it work immediately in practice.

Test plan

  • codecheck (ruff + format + mypy + 128 tests) green locally
  • semantic-release --noop version --print parses the new config without error
  • CI on this PR
  • After merge: next merge of any kind cuts a release

…efix

## Summary
Drops the requirement that contributors remember `feat:`/`fix:`/etc.
prefixes for a release to happen. From now on, every merge to main
ships at least a PATCH release; the conventional-commit prefixes are
optional and only matter for choosing between PATCH / MINOR / MAJOR.

This matches a continuous-deployment philosophy: every change that
reaches `main` is, by definition, a change worth shipping. Lowers the
cognitive load on contributors and removes a class of "I merged but
nothing got released — why?" support questions.

Trade-off: more releases (small typo fixes also bump the version).
That is intentional — the version number is treated as a counter of
"changes shipped to users", not a curated narrative of major events.

## Change Log
- `pyproject.toml::[tool.semantic_release.commit_parser_options]`:
  `default_bump_level` flipped from `0` (no release if no qualifying
  commits) to `1` (any commit triggers PATCH). Inline comment now
  enumerates the new behavior table for future maintainers.
- `AGENTS.md` Rule 15 (Packaging & Versioning): rewrote the bullet
  about the default release path to reflect the unconditional-release
  policy. Conventional-commit prefixes still unlock finer control,
  they are no longer required.

## Risks
- More frequent PyPI releases. Each one is small (one PR's worth of
  changes), so this is not a meaningful infra cost. PyPI does not
  rate-limit at this volume.
- The version number escalates faster. We are now on 1.0.x; with this
  policy each merge yields 1.0.x+1 or higher. Acceptable trade-off
  for the simpler contributor experience.

## How this is verified
- `codecheck` (lint + format + mypy + 128 tests) green.
- `semantic-release --noop version --print` parses the new config
  without error.
- After this PR is merged, the next merge of any kind (even a typo
  fix or a docs-only change) will cut a release. We will see this in
  practice immediately.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@xergioalex xergioalex merged commit 6aa16bc into main May 2, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant