Communication of breaking changes

[jimeh]

The recent patch releases of v2.0.8 and v1.6.12 have seemingly caused various issues and headaches for a lot of people due to them containing a non-backwards compatible breaking change. (#1432, #1433)

I think things would have gone down a lot smoother if a warning had been communicated in one form or another. I've looked in all reasonable places I can think of where a breaking change warning might be placed, and I have not found one. Apologies though if there is one, and I've simply managed to miss it somehow.

Going forward, I have a few questions which might help prevent this happening again:

1. Can communication of breaking changes be improved? A mention in the changelog at least would be great.
2. Can the changelog be updated at the same time as cutting new releases? As 2.0.8 missing from CHANGELOG #1429 and Add 2.0.8 and 1.6.12 to CHANGELOG #1430 show, the changelog has lately been updated at some point after new releases.
3. Is using Semantic Versioning an option?
4. Is using something like Conventional Commits and/or Semantic Release an option to help automate both releases and changelog generation?

[rafaelfranca]

1. Can communication of breaking changes be improved? A mention in the changelog at least would be great.

Yes. We do that, but some times we forget. We are all humans.

2. Can the changelog be updated at the same time as cutting new releases? As #1429 and #1430 show, the changelog has lately been updated at some point after new releases.

Yes. We also do that, some times we forget.

3. Is using Semantic Versioning an option?

We follow semantic versioning, but semantic versioning don't specify what should be made with security bugs, and that was exactly what cuased the problem here.

4. Is using something like Conventional Commits and/or Semantic Release an option to help automate both releases and changelog generation?

I don't know how that could have helped in this situation.

Thank you for the issue, but instead of trying to change other people workflow why don't we focus on actually opening a PR with a CHANGELOG entry? I'm pretty sure that would be more helpful.

[jimeh]

As you suggested, I've created a PR (#1459) to add a breaking change warning for 2.0.8 and 1.6.12.

Also, apologies if I came off at all as being offensive. I simply wanted to start a discussion about if any form of automation could help reduce the chance of people being caught out by a similar situation in the future.