This repo has no tags, no CHANGELOG and no release. There is no way for anyone to say which version of these skills they are using.
That matters more here than it would for a normal library, because of how the skills get consumed. People symlink the whole folder, or copy a single skill directory into their own project. Once a folder is copied it carries no provenance, and "I took jpa-patterns in March" is not something anyone can act on. With 144 forks the same problem appears from the other side: a fork owner has no point to diff against to see what moved upstream.
A release checklist has been sitting in my notes since the beginning and never got done. This issue is to finish it.
Proposal
Cut v1.0.0 once #5 lands.
v1.0.0 rather than v0.x. The skills have been stable for months and are in real use, and a 0.x prefix reads as "not ready" to anyone evaluating whether to adopt them. For a collection of markdown files a stability promise is one I can actually keep: under a major version, skill names and directory layout do not change, which is the only thing a symlink or a copy depends on.
Release notes
Not a dump of git log. A raw commit list tells a reader nothing about which skills changed, which is the one thing they care about.
This repo ships a changelog-generator skill and does not use it. The first CHANGELOG should be generated with it. The output is better than a commit dump, and being able to say the collection uses its own skills is worth something on its own.
One caveat: roughly half the commit history predates any convention, so the first CHANGELOG will need hand editing. From v1.0.0 onward, conventional commits keep it clean.
Decisions to make
Version anchor. Two options:
- A
VERSION file at the root. A workflow triggers on changes to it, reads the version, skips if the tag already exists, and publishes. The release becomes a reviewable PR alongside the CHANGELOG entry.
- Tag driven, a workflow on
push: tags: 'v*'. Simpler, but the release is not reviewable before it happens and it depends on remembering to tag.
Leaning towards the first. There is no build artifact here, so the version file is purely a marker, and routing the release through a PR suits a project that goes quiet for stretches.
When to automate. The workflow can wait. v1.0.0 can be cut by hand, and the automation added once cutting one by hand starts to feel like a chore. Writing the automation first would mean automating something that has happened zero times.
Out of scope
Release assets. There is nothing to attach, the source archive GitHub generates is the artifact.
Publishing to a package registry. Not until someone asks for it.
This repo has no tags, no CHANGELOG and no release. There is no way for anyone to say which version of these skills they are using.
That matters more here than it would for a normal library, because of how the skills get consumed. People symlink the whole folder, or copy a single skill directory into their own project. Once a folder is copied it carries no provenance, and "I took jpa-patterns in March" is not something anyone can act on. With 144 forks the same problem appears from the other side: a fork owner has no point to diff against to see what moved upstream.
A release checklist has been sitting in my notes since the beginning and never got done. This issue is to finish it.
Proposal
Cut v1.0.0 once #5 lands.
v1.0.0 rather than v0.x. The skills have been stable for months and are in real use, and a 0.x prefix reads as "not ready" to anyone evaluating whether to adopt them. For a collection of markdown files a stability promise is one I can actually keep: under a major version, skill names and directory layout do not change, which is the only thing a symlink or a copy depends on.
Release notes
Not a dump of
git log. A raw commit list tells a reader nothing about which skills changed, which is the one thing they care about.This repo ships a
changelog-generatorskill and does not use it. The first CHANGELOG should be generated with it. The output is better than a commit dump, and being able to say the collection uses its own skills is worth something on its own.One caveat: roughly half the commit history predates any convention, so the first CHANGELOG will need hand editing. From v1.0.0 onward, conventional commits keep it clean.
Decisions to make
Version anchor. Two options:
VERSIONfile at the root. A workflow triggers on changes to it, reads the version, skips if the tag already exists, and publishes. The release becomes a reviewable PR alongside the CHANGELOG entry.push: tags: 'v*'. Simpler, but the release is not reviewable before it happens and it depends on remembering to tag.Leaning towards the first. There is no build artifact here, so the version file is purely a marker, and routing the release through a PR suits a project that goes quiet for stretches.
When to automate. The workflow can wait. v1.0.0 can be cut by hand, and the automation added once cutting one by hand starts to feel like a chore. Writing the automation first would mean automating something that has happened zero times.
Out of scope
Release assets. There is nothing to attach, the source archive GitHub generates is the artifact.
Publishing to a package registry. Not until someone asks for it.