https://pantsbuild.org/ logo
c

curved-television-6568

09/17/2021, 3:13 PM
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.
e

enough-analyst-54434

09/17/2021, 3:25 PM
To make sure we're looking at the same thing, are you referring to, for example, this: https://github.com/pantsbuild/pants/blob/main/src/python/pants/notes/2.6.x.md Which is linked from the matrix here: https://www.pantsbuild.org/docs/changelog
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.
c

curved-television-6568

09/17/2021, 3:28 PM
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…
h

hundreds-father-404

09/17/2021, 3:33 PM
Good idea! I like that change
w

witty-crayon-22786

09/17/2021, 4:13 PM
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
h

hundreds-father-404

09/17/2021, 4:23 PM
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
c

curved-television-6568

09/17/2021, 4:25 PM
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.)
h

hundreds-father-404

09/17/2021, 4:52 PM
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
changelog.py
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