v2.9.0

[k00ni]

https://github.com/smalot/pdfparser/releases/edit/untagged-657a61b25de4ea1a2a40 (collaborators only)

CC @j0k3r

[j0k3r]

It's ok to me, one question: should we separate internal changes from public changes? I mean, changes to CS or Scrutinizer is useless from the user POV. The user only wants to know what might inpact their code/library/product. What do you think?

[k00ni]

should we separate internal changes from public changes? I mean, changes to CS or Scrutinizer is useless from the user POV. The user only wants to know what might inpact their code/library/product.

I would not separate, because we follow the Semantic Versioning rule set. It says (https://semver.org/#spec-item-7):

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

IMHO internal changes are part of the software life cycle and affect the software itself. You are right, our users probably don't care much about internal changes. To me, its more about a general view on the software itself (including documentation, tests, artifacts like PDFs) rather than what our users "see".

How would you enumerate our releases if we don't increase the minor version, when internal changes happened?

[j0k3r]

I wasn't asking to change versionning, just to separate the internal stuff in the changelog :)

[k00ni]

I wasn't asking to change versionning, just to separate the internal stuff in the changelog :)

If I understand you correctly, you mean keeping the release notes for each release free of internal changes? And only release a new version if there were changes which are of interest of the user?

[j0k3r]

I'm not talking about releasing or not internal changes. I'm just talking about what we should write and how in the release note.

I mean separate what is important for the end user from what might be important for people maintaining the lib. As a end user I don't really care if CS-Fixer is up to date, it adds no value, you see what I mean?

Taking the release not for the 2.9.0, it can be like that:

## What's Changed
* Fix returning empty text in some cases by @xAzoom in https://github.com/smalot/pdfparser/pull/666
* Baseencoding fallback by @GreyWyvern in https://github.com/smalot/pdfparser/pull/669
* Check for binary content in formatContent() before a problematic regexp by @GreyWyvern in https://github.com/smalot/pdfparser/pull/676

## Internal changes
* Fixed latest coding style issues and refined a few PHP doc entries to match types by @k00ni in https://github.com/smalot/pdfparser/pull/677
* Fixes Scrutinizer integration (mostly failing tests) by @k00ni in https://github.com/smalot/pdfparser/pull/682
* Fixed a few coding style issues by @k00ni in https://github.com/smalot/pdfparser/pull/670

## New Contributors
* @xAzoom made their first contribution in https://github.com/smalot/pdfparser/pull/666

**Full Changelog**: https://github.com/smalot/pdfparser/compare/v2.8.0...v2.9.0

[k00ni]

I'm not talking about releasing or not internal changes. I'm just talking about what we should write and how in the release note.

The changes mentioned in your example make sense. So, its not about hiding internal changes but to separate them visually. My bad, I think I get your point now.

We can definitely do that for future release.