Changelog updates

[katspaugh]

Updating the changelog manually is tedious and IMHO shouldn't be a blocker for pull requests.
I suggest we automate this in the release workflow instead, because it's essentially the list of commits between two versions.
Something like git log --pretty=format:'* %s' vX.X.X...vY.Y.Y > CHANGELOG.md should do the trick.
WDYT @thijstriemstra and everyone?

[entonbiba]

@katspaugh yea that makes it more clean and automated I agree

[katspaugh]

Well, that's also a fair a point. I agree that taking a conscious effort to describe what you've done is important.

Automating it really isn't difficult tho, here's an example which relies on the version in package.json but it can also be adapted to use regular git tags.

I think adjusting the PR title (which then becomes the message of the squashed commit) if necessary is about the same effort as updating the changelog, but people wouldn't have to write it twice.

[thijstriemstra]

I welcome PRs that make things easier!

[entonbiba]

@katspaugh it would it be pulling the PR titles only right without the descriptions?

[katspaugh]

Yes

[entonbiba]

that's great, then it would be a lot cleaner to keep it consistent and accurate with titles.

[thijstriemstra]

Automating it really isn't difficult tho, here's an example which relies on the version in package.json but it can also be adapted to use regular git tags.

So yea, 3b9d58c is not mentioned in the changelog. I've always made a lot of effort to get the changelog right by requiring contributors to add an entry to prevent situations like that. Besides that I had to make multiple corrections to the changelog in a review for 6.5.0. So this is costing maintainers a lot of work. I'm frustrated to see my work being undone here without a proper alternative/solution.

[katspaugh]

It's unfortunate you didn't make it to the call, I wanted to discuss this among other things.

I see several problems with the manual changelog:

• It's an additional round of PR gatekeeping which makes it more difficult to contribute
• it's redundant because the PR title and description should already contain all the necessary info, and it's much easier to edit those than making another commit
• the entry becomes stale if another release is made in the meanwhile
• it creates git conflicts when multiple people edit the same version log

And most importantly, like I said in the post above, it's easy to automate. I just haven't gotten around to adding an action for it. Will do so soon.

[katspaugh]

In addition to the changelog automation, I'd like to propose a new release procedure:

• Create a new branch, e.g.production
• To make a release, push master to a new branch (e.g. release/6.6.0), update the version in the package.json, and make a PR from this branch to production
• Once the PR is merged, GH workflows are triggered on push to the production branch
• Master remains as a dev branch, where new changes can be pushed independently of an open release PR

[katspaugh]

Here's a PR for both the changelog automation and the new release routine: #2710

I'm now having second thoughts about adding a production branch. It might be an extra hurdle in our case. Perhaps we should stick with just master.

[thijstriemstra]

It might be an extra hurdle in our case

Agreed.