Please use SEMVER on this package!

[iget-master]

Hi,

This is an appeal for package maintainers to use semantic versioning on this package.

The release of v0.20.0 introduces breaking changes on a patch version, this causes a lot of issues for people that relies on semver.

[jdreesen]

The release of v0.20.0 introduces breaking changes on a patch version

Which is allowed, according to SemVer 2.0.

[iget-esoares]

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards 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.

Patch and minor version cannot contain backward incompatible changes. Major versions can.

Since even after a lot of years this package remains on 0.x.x, it's clear that no backwards compatible changes should exists, but it does.

On release note for v0.20.0 it says that php 5 support is dropped. And more than this, it doesn't say that the interface for Transformer changed introducing the array type for some fields.

My suggestion is that any future breaking change increment this package to 1.0.0 and so on.

Also I suggest mantainers to use the well adopted conventional-commits pattern and the awesome semantic-release package that makes easy to automatically release versions that respect the semver.

[jdreesen]

Patch and minor version cannot contain backward incompatible changes. Major versions can.

True, but the definition you cited is for x.y.z | x > 0, while this package is x = 0, for which the spec says:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Apart from that, dropping support for old PHP versions in minor Versions does not violate SemVer! Composer will just not update to the new version if your PHP doesn't support it.

[colinodell]

Apart from that, dropping support for old PHP versions in minor Versions does not violate SemVer!

Correct - SemVer only cares about the public API of the package, not its dependencies (including PHP).

[iget-master]

@jdreesen Of course. the package is x=0 since 2013! This look correct for you? I'm using this package in a production environment almost since 2014 or 2015. It does looks pretty stable for me, don't?

My question here is about why we still on x=0?

Also @colinodell the public api did changed, sightly but it did. The addition of the array type on the TransformerAbstract breaks any application that uses it.

This issue is not about complaining because it broken my app, but about suggesting to move on and make this excelent package version reliable.

Moving on to v1.0.0 and respecting semver IMHO is a must.

[iget-master]

We are talking about a package with 28M installs on packagist, 3.5K stars, 500 public dependents (most of the dependents probably are private projects).

[KorvinSzanto]

This issue is not about complaining because it broken my app, but about suggesting to move on and make this excelent package version reliable.

I fully agree, our focus at this point is getting to 1.0.0. Don't be too surprised if we encounter more breaking changes to get there but know we're doing our best to preserve compatibility as we go.