#development
Title
c
curved-television-6568
09/17/2021, 3:13 PMRegarding 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 PMTo 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 PMyes, 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 PMGood idea! I like that change
w
witty-crayon-22786
09/17/2021, 4:13 PMwe 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 PMThe 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 PMI 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 PMThe 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