Regarding the release process, I have a suggestion...
# development
Regarding the release process, I have a suggestion. Reading the changelog, it is very.. fractured. I suggest folding all dev and rc log entries into the stable release, once it is released. That way, it’ll be much easier to navigate, when upgrading for instance. As you’ll only consider each stable release, it is not that relevant in which dev or rc a certain feature was introduced, or bug fixed.
To make sure we're looking at the same thing, are you referring to, for example, this: Which is linked from the matrix here:
You must be looking at something else, because that's unified. All 2.6.x activity in time order latest to earliest dev0 in 2.6.
Ah, ok - re-read your sentences. So you think the section headers basically are noise?
I don't think I agree this is any great impediment, but I get your complaint.
yes, it clutters up so it’s harder to see where the stable releases are (i.e. the boundaries for what applies when going from say 2.6.0 to 2.6.1)
👍 1
Yeah, I didn’t really expect any action on it…
But I have a hard time building a picture of what features are introduced, for instance, between two stable version, as there’s a bunch of bug fixes and other headers in between…
Good idea! I like that change
we could also adjust the header level
so that unstable releases have a smaller header / are nested
👍 1
(but agreed in general that the changelog process is overly manual and still doesn’t have a great outcome, heh)
👍 1
The utility I think for having distinct sections is it makes it easier for people migrating from dev2 to dev3, etc. But I'd rather bias towards people jumping from 2.6.0 to 2.7.0, rather than dev2 to dev3 And distinct sections is easier for people probably to figure out which release broke things? But that latter reason is a poor one, that's what git is for
I don’t want to introduce more manual work which impedes the release process. Perhaps a tool could preprocess the description that lands on pypi for instance. That way the level of detail can be preserved in the changelog document.
Going from dev2 to dev3 would still be in there, until a stable is released, was my idea any way
The devs working on backstage keep a list of “changeset” records, that builds up to each release, with tooling to generate changelogs etc. They have another issue, however, and that is that they have too many moving targets they track… but at least it is automated 😛 Those tools are written in node, however. Think they’ve borrowed the concept from some other project (can’t recall which atm.)
The main thing we want is for PR authors to start choosing the category before merging, e.g. via GitHub labels. Then, our script can query the label to autocategorize the changelog, whereas
right now only grabs the changes The blocker is how to enforce that a label is set via GitHub Actions. Asher tried a year ago, and it had some issues. Maybe the landscape is different now