Set up per-extension changelogs and versioned releases for a Pi extensions monorepo
Session from pi-extensions-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
Click a segment to jump to that moment
32msession
0interventions
by library · 1d
GOAL
Decide how to handle changelogs and releases across a multi-extension repo, then implement per-extension changelogs, versioning, and GitHub releases.
- +0Prompt · +0I have separate readmes per extension and a changelog only for usage-extension. How should I handle changelogs and releases now that I have contributors/users?
- +0mPrompt · +0mOk can you review the codebase and help me figure out how to proceed here?
- +1mAgent did · +1mExplored the repo structure, read all extension READMEs, checked for existing CHANGELOG.md and package.json files, and inspected usage-extension's code and changelog history.
- +3mAgent did · +3mRecommended starting per-extension SemVer releases now, skipping WIP ones like relaunch, moving usage-extension's inline changelog into its own CHANGELOG.md.
- +21mPrompt · +21mLet's do that. Version everything except relaunch, mostly at 0.1.0, with /usage at 0.1.2 since it has more history. Does that make sense?
- +21mAgent did · +21mEdited README changelog sections for six extensions, created CHANGELOG.md files for each (initial 0.1.0 releases) and usage-extension/CHANGELOG.md (0.1.2), and added a RELEASING.md documenting the per-extension tag format and release workflow.
- Break · 37m away, not counted
- +25mPrompt · +25mLet's commit/push. Agree with dropping current versions section; then tag, ensure release notes exist, commit and push.
- +25mAgent did · +25mTrimmed the version list from RELEASING.md, staged and committed all changelog/README changes as one commit, tagged each extension with its version, and pushed the commit and tags to origin/main.
- +31mPrompt · +31mYeah let's do that. Commit/push when done, be sure to give recognition.
- +32mOutcome · +32mPublished GitHub releases for all 7 tagged extension versions (6 at 0.1.0, usage-extension at 0.1.2) with release notes and contributor thanks; single commit de6145a (15 files changed) pushed to main alongside all tags.
VERDICT
Next time I'd start the first prompt by naming the versioning scheme I want (per-extension SemVer, initial 0.1.0 baseline) so the agent doesn't have to propose and I don't have to confirm it separately. Having it first survey the whole repo before proposing a plan worked well — the recommendation to skip relaunch and split usage-extension's changelog out was exactly what I wanted, so I just said 'do that' and it executed cleanly through commit, tag, push, and GitHub release creation.