Promote patch releases as regular releases in changelog / GH

[MasterOdin]

Any major or minor release is given a regular GH release and a CHANGELOG header like so:

Version 1.27.0, 2022-04-07
--------------------------

patch releases on the other hand are only made as tags and found in the CHANGELOG as (also just as a section of the minor release?):

Patch release 1.27.1, 2022-04-08

I would propose to just have a unified style (what goes on for major / minor) for all release types, and that patch releases are no less insignificant as they can contain a number of bug fixes and things that may greatly affect users depending on bug severity. They are also shown as equal weight on PyPI as any other version.

For an end user, I feel like this could create some contention where they might see a new version on PyPI (1.27.3) and when they go to the GH repo, they're not shown this new version readily, and so may (mistakenly) conclude that there's some mischief going on where the PyPI release was made in some malicious fashion vs what's on GH.

[MartinThoma]

I like it! I did it like that for other projects but didn't want to break the style.

[MartinThoma]

However, I would not change the existing ones (simply because I'm too lazy; feel free to do so :-) )

[MasterOdin]

Yeah, there's only 4 patch releases in the changelog at this point so better to make the change now before accumulating more! I'm happy to do the legwork on this. On that vein, are you alright with me then:

• Making a PR to update the changelog (along with reworking it so patch release notes follow style of major / minor releases)?
• Making a GH release for 1.27.1 - 1.27.3?

For 1.27.1 and 1.27.2, it would require first creating a branch from the relevant commit, and then making the release on that branch. For 1.27.3, the commit is recent enough can just point to that without first creating a branch.

[MartinThoma]

Making a PR to update the changelog (along with reworking it so patch release notes follow style of major / minor releases)?

Sure! Thank you already 🙏

Making a GH release for 1.27.1 - 1.27.3?

The Github tags exist already and it's possible to create releases from them:

Talking about this: Where do you see the value of Github releases?

[MasterOdin]

Talking about this: Where do you see the value of Github releases?

For a library that doesn't have any build artifacts, I'll usually use releases in lieu of a dedicated changelog file, as well as hook up GH actions to the release published event to then further publish to external sites (like PyPI or npm). If the library was being packaged by a third party manager, I think some downstream managers (like homebrew) prefer to use releases. For how PyPDF2 currently exists and functions, I think releases brings little total value over other methods of making version known.

I'd be equally fine deleting all existing releases and only using tags, but for me, if releases has been used in the past and exist, then the latest release is promoted to me in multiple places in the UI over any later tag, and so just makes me momentarily concerned that GH says latest release is 1.27.0 and PyPI shows 1.27.4 and why the discrepancy?!

I would add that given a well formed changelog, it should be possible to create a GH action that just automatically creates a release on a new tag and include relevant changelog info so that makes it so that your current release workflow (create commit, make tag, manually publish to PyPI) need not change.

[MartinThoma]

Nice idea! #748