Skip to content

chore: release main#78

Closed
StefanSteiner wants to merge 2 commits into
mainfrom
release-please--branches--main
Closed

chore: release main#78
StefanSteiner wants to merge 2 commits into
mainfrom
release-please--branches--main

Conversation

@StefanSteiner
Copy link
Copy Markdown
Contributor

🤖 I have created a release beep boop

1.0.0

1.0.0 (2026-05-28)

⚠ BREAKING CHANGES

  • v0.3.0 reshapes the public hyperdb_api::Error enum into a flat canonical structure (no Box cause channel, no kind() method, no Other catch-all variant), and its constructor surface (Error::new and Error::with_cause are deleted in favor of domain-specific snake_case constructors). It also changes the FromRow trait signature from fn from_row(row: &Row) to fn from_row(row: RowAccessor<'_>), deletes the blanket 1/2/3/4-tuple FromRow impls, deprecates Connection::begin_transaction/commit/rollback (use the RAII guard at Connection::transaction() instead), introduces a new Error::InvalidOperation variant, and changes Error::Cancelled and Error::Closed from tuple to struct variants carrying structured sqlstate. Every variant has a snake_case constructor; the FromRow derive lives in a re-exported hyperdb-api-derive crate. See MIGRATING-0.3.md for migration recipes.

Features

  • stabilize v0.3.0 public API bundle (#77) (ac39b2c)

This PR was generated with Release Please. See documentation.

StefanSteiner added a commit that referenced this pull request May 29, 2026
Configures release-please to bump 0.x.y → 0.(x+1).0 on a BREAKING
CHANGE: footer instead of bumping straight to 1.0.0. The default
release-please behavior for any 0.x.y release-type:simple package is
that BREAKING CHANGE triggers a 1.0.0 bump; bump-minor-pre-major:true
overrides that to "BREAKING CHANGE while < 1.0.0 only bumps minor".

Why now: PR #77 (the v0.3.0 rollup) carries a BREAKING CHANGE: footer.
release-please opened release PR #78 proposing 1.0.0. We closed #78
without merging — the manifest is still 0.2.3, no tag was cut. With
this config change, the next release-please run will recompute against
main and propose 0.3.0 instead of 1.0.0.

Schema verification: bump-minor-pre-major is a documented field on the
release-please config schema at both the top level (acts as default
for all packages) and the per-package level. Verified against
https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json
and the implementation in release-please src/manifest.ts:1746-1747
which reads pathConfig.bumpMinorPreMajor ?? defaultConfig.bumpMinorPreMajor.
Setting both explicitly for defense-in-depth.

This config is evaluated against current commits at run time, so it
applies retroactively to the BREAKING CHANGE: footer already on main.
No need to amend the rollup commit or cherry-pick history.

Note: the closed PR #78 still has the autorelease: pending label. That
label only matters on OPEN PRs; release-please's matcher
(findOpenReleasePullRequests) ignores closed ones unless they carry
autorelease: snooze. PR #78 is therefore invisible to the next run,
which will open a fresh release PR with the corrected 0.3.0 proposal.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant