Running `github-release` only for the most recent release
jwodder opened this issue · 10 comments
The docs for the scriv github-release command imply that it will create/update releases for every version documented in the CHANGELOG, which I suspect will lead to problems in our case. Is there a way to only create/edit the most recent/topmost release in the CHANGELOG?
I see what you mean: this could make it hard to switch to scriv. Can you say more specifically what problem would happen in your case?
First of all, updating every release just seems like a waste of resources — and arguably a violation of the principle of least surprise — when, in 99.99999% of cases, the user will just be adding a single release.
For the project in question, it has a lot of releases and has experimented with many different methods for composing changelogs and release notes. There was a point when all hyperlinks in the changelog were formatted as [link text][], with the URLs for the links given at the bottom of the file, which won't work if the changelog sections are naïvely split up based on headers. There are likely also releases whose release notes don't equal their changelog entries, and blasting away the old notes just seems like the wrong thing to do.
Thanks, I understand that old entries made with a different tool shouldn't be blindly overwritten.
About the resources: scriv doesn't literally write every release: it updates old releases only where there's a change, which is hardly ever, but sometimes happens.
There are two ways we could solve this:
- A flag to only consider the latest release
- A setting which is the release when scriv was adopted, then all releases from that point on would always be considered.
Since #1 was your suggestion, I'll guess that would be your preference.
I agree that having a flag to consider only the latest release (i.e. 1. above) would have been great!
Honestly it might make more sense for the default to be only the latest release, and have an option to consider all the releases. I think that will line up best with people's expectations and workflow, and will make adoption easiest. It will be a breaking change, but we are still <1.0.
FWIW -- totally agree ;-)
This is now implemented in commit 52800b0. Can you try it out before I make a release?
This is now released as part of scriv 0.17.0.
THANK YOU!