Skip to content

chore(main): release 0.57.2 - #514

Open
Ank-KhoaHo wants to merge 1 commit into
mainfrom
release-please--branches--main
Open

Ank-KhoaHo wants to merge 1 commit into
mainfrom
release-please--branches--main

Conversation

@Ank-KhoaHo

Copy link
Copy Markdown
Owner

🤖 I have created a release beep boop

0.57.2 (2026-09-21)

Fixed

  • ci: add .dockerignore so the container guard cannot pass on host build output (d9291ba)

This PR was generated with Release Please. See documentation.

@Ank-KhoaHo

Copy link
Copy Markdown
Owner Author

Before merging this

Merging tags the version and publishes both packages to nuget.org. A published version can be
unlisted but never edited
, so everything below is cheaper now than at any point afterwards.

  • Read the changelog entry in the diff. An entry that is empty, or that says nothing a
    consumer would act on, is a signal to let more changes accumulate rather than release now.

  • Does anything here CHANGE existing behaviour? release-please files every feat: under
    Added, which reads as a new capability. A changed default, a different output, or a new
    exception from a call that used to succeed is none of those — and a consumer upgrading will
    not learn about it from an Added line. Move it to Changed by hand, with the one-line
    migration.

    Not hypothetical: **0.13.0** changed generated documents from whatever the reader's template
    chose to A4, and the entry said only "defaulting to A4", filed under *Added*.
    
  • Does the nuget.org <Description> still describe what ships? Check it against the
    generated docfx/guides/capabilities.md. CI proves the
    field is non-empty; nothing can prove it is true. It described a smaller library than
    shipped for four releases.

  • Once you arm auto-merge, this PR is finished. Pushing to it afterwards is a race that is
    lost silently — git push reports success either way, and the commit is orphaned on a dead
    branch. Anything further goes on a new branch.


Editing CHANGELOG.md on this branch is all that is needed. The GitHub Release body is derived
from that entry automatically after merge, so the two cannot drift apart — they did on 0.27.2,
where the curated changelog and the published release notes disagreed until somebody noticed by hand.

@github-actions

Copy link
Copy Markdown
Contributor

This entry is still release-please's generated text.

0.57.2: 1 generated item(s), 0 line(s) of human content.

  NOTHING HAS BEEN CURATED. Every line is still release-please's text, derived
  from commit titles - so a behaviour change committed as `feat:` is sitting
  under Added described as a new capability, and anything that arrived inside a
  squashed stacked PR may have no entry at all.

  If you curated this already, a later merge to main has REGENERATED it.
  Curate immediately before merging, with nothing else in flight.

Updated whenever this branch changes - by release-please regenerating the entry, or by a curation being pushed. Re-read it immediately before merging.

This branch has not been deployed

No deployments
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