docs: require a changelog fragment per change#122
Merged
Conversation
Adds the contributor-facing half of the scriv changelog process for the compiler: a pull request template whose checklist asks for a changelog.d fragment, and a "Changelog fragments" section in docs/VERSIONING.md. The scriv config, CHANGELOG.md, and the release flow already landed in 0.3.0.0. This is the compiler's piece of the ecosystem-wide changelog adoption (#101).
There was a problem hiding this comment.
Pull request overview
This PR strengthens the contributor-facing changelog workflow in purescript-lua by documenting the “scriv fragment per user-facing change” process and reinforcing it via a PR checklist, aligning this repo with the broader ecosystem-wide scriv adoption described in #101.
Changes:
- Documented the per-change
changelog.d/fragment workflow and howscriv collectfeeds releases. - Added a PR template checklist item requiring a changelog fragment for user-facing changes (and clarifying when none is needed).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| docs/VERSIONING.md | Adds a “Changelog fragments” section describing scriv create per change and scriv collect on release, with a link to ADR 0009. |
| .github/pull_request_template.md | Introduces a PR template checklist to enforce the fragment workflow on user-facing changes. |
Addresses Copilot review on PR #122: builds/tests run inside `nix develop` (see .github/copilot-instructions.md), so the fourmolu/hlint/cabal items now say so.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
docs: require a changelog fragment per change
Closes #101.
This is the umbrella PR for the ecosystem-wide changelog work. The compiler already shipped its scriv config,
CHANGELOG.md, and release flow in 0.3.0.0; what was missing was the contributor-facing process and the matching scaffold across the package set. This PR adds the former, and the rest landed in the other repos (linked below).In this repo
changelog.d/fragment on any user-facing change.docs/VERSIONING.mddescribingscriv createper change and how it folds into a release.Both are docs/CI only, so this PR ships no fragment of its own.
Across the ecosystem (issue #101 scope)
scriv collectrelease step; the set gets its own backfilledCHANGELOG.md.scrivin the dev shell, anAGENTS.mdrelease note pointing at the scriv flow, and aCHANGELOG.mdthat records the Lua fork's release line above the preserved upstream history. The FFI-campaign tags ([fork-ffi] arrays: traverse1Impl — Faulty JS->Lua translation of thenew ConsCell(...)/ `new… #73-[fork-ffi] enums: toCharCode crashes on a lone code-unit byte (regression in v6.1.1) #102) are backfilled; forks with no campaign release carry the scaffold only. Pushed straight tomasterper the fork convention (nosrc/change, so no tag or set bump).Note on ADR 0006
ADR 0006 had decided "no per-fork changelog" as deliberately light process. The FFI campaign changed that: the fork tags carry one line each and the only aggregation point was the set-bump commit messages. ADR 0009 reverses just that clause and leaves the tag-driven release flow intact.