RELEASE: document release procedure. #30
Conversation
ericonr
force-pushed
the
release-v0.4.0
branch
from
cf8a8b1 to
91d76a5
Compare
There was a problem hiding this comment.
Will #16 be closed by this PR? At first, I've thought about maintaining a CHANGELOG.md to track changes.
Will we keep that only in GitHub releases? That wouldn't go with the Git history if we move to another repository host.
RELEASE.md
Outdated
| A new commit should be created in the `main` branch, updating the version used | ||
| in [Dockerfile](./Dockerfile) to `vX.Y.Z-git` to avoid usage of the `main` | ||
| branch in actual deployments. |
There was a problem hiding this comment.
Any standard message for this? I've been thinking about something like "Post-release development version bump".
I still prefer vX.Y.Z-dev, but I'm okay with -git as well.
There was a problem hiding this comment.
Post-release development version bump
I'd be okay with something like that. Will add it.
I didn't remember what version we had settled on. I'm okay with -dev.
RELEASE.md
Outdated
| notes" feature, but special care should be taken to split the merged PRs into | ||
| the "Breaking changes", "New features", and "Bug fixes" categories. The first | ||
| section of the release description should be "Who needs this update" and | ||
| describe the most relevant changes and package updates and what their effect | ||
| is. |
There was a problem hiding this comment.
How about keeping the list from #16 explicit here? It might make it easier to look after specific (breaking) changes in large change sets.
There was a problem hiding this comment.
That's a good idea, will add it.
Is there tooling to automatically generate the changes? I had started writing a changelog myself, but it's a lot of manual work. And having all commits misses out on the grouping by PRs, which I find useful. And having a link to the discussion about a given change, instead of only the commit, seems more useful to me as well. That's why I thought about relying on github releases. |
Not one that I'm familiar with. github-changelog-generator has a list of alternatives for doing that.
I agree. As we discussed in-person, let's stick with progressive writing of the changelog grouped by PR. |
ericonr
force-pushed
the
release-v0.4.0
branch
from
5c3880d to
9974e59
Compare
It covers only the differences between the currently unreleased version and v0.3.0. The PR list was generated using GitHub's new release page, and manually sorted.
This way development can still happen in the main branch, but users will only use actual released versions.
ericonr
force-pushed
the
release-v0.4.0
branch
from
9974e59 to
c6ec133
Compare
No description provided.