Change in minor release should have been listed as a breaking change

[oscarvaldes]

The change to this file 7bc8f76?diff=split#r77947752 is a breaking change.

To Reproduce:

upgrade from 5.0.0 or prior to latest (currently -- 5.1.1)

Expected behavior
No breaking changes in minor or patch versions

[budde377]

This is absolutely fair feedback. We've recently restructured our versioning be separating the two packages, this'll allow us to make proper semver releases in the future and prevent this from happening again.

[vincenzopalazzo]

Thanks for reporting this, we are missing this feature in the changelog, but add it to my to-do list vincenzopalazzo/changelog.dart#21 I will try to patch this after my holidays.

In addition, I don't like these "breaking change" rules because to follow these rules means that if we introduce a bug and after a while we have to fix it and this introduces a breaking change we need to have to bump the release to a new major release, and this to me has no sense.

I will propose a deprecation field in the changelog, and we try to keep this deprecation field for a couple of releases (major or minor), and when the period is over we remove it by adding a new changelog filed with "remove".

This has the following benefit:

• avoid having users that use versions with bugs only because are lazy to update to a version that contains breaking changes
• give the possibility to have feedback during the development process from the compiler that there is some deprecated stuff that you need to remove, and you have X time to do this. With a good development live cycle, you should be able also to have 0 costs to keep your library always update.

I was able only to find one drawback:

• painful for the maintainers, because bumping a new major release with an introduction of a breaking change is easy but we are missing users (lazy ones).
• Any others?

In addition, we have also a very very very long beta process that can give your a preview of the change inside the release, we make a new beta version almost every time we merge a PR.

[insidewhy]

In addition, I don't like these "breaking change" rules because to follow these rules means that if we introduce a bug and after a while we have to fix it and this introduces a breaking change we need to have to bump the release to a new major release, and this to me has no sense.

Why does it matter to upgrade the major version in this case? Especially if it helps people depending on your package? It has sense. The old way of thinking is that versions are seen as a indication of "how much" has changed rather than backwards compatibility. But I'd argue that this is what has "no sense" since using versions to indicate compatibility actually has utility.

[vincenzopalazzo]

No, do not make sense if the breaking change does not depend on the library, the breaking change should happen under a deprecation period!

The people should stay updated with the last version of the library to help and repay our time spend on the new release!

[insidewhy]

In an ideal world people could but I don't know if they should. Nobody owes you anything just because you gave them something for free. The point of open source is to give without expectation. Obviously you disagree with the standard practices when it comes to versioning but I don't think your reasoning is objective enough for it to be considered "worth it".

[insidewhy]

Describing users as lazy is actively harmful. Not having time to operate perfectly doesn't make someone lazy, in fact many of the hardest workers are facing exactly this conundrum because they take on so much work.

[vincenzopalazzo]

I do not want keep going this chat longer that that because is just a chat, if somedays we meet in some conference came to me and we solve this discussion like two normal person.

If you walk inside the semiversion spec https://semver.org/#how-should-i-handle-deprecating-functionality you noted that my argue is not out of spec in any point!

This is an example where I prevent a breaking change #1197 by applying the correct spec.

If there is some point that it is out of spec in our release, please open a issue, but before read all the semi version spec!