Post

Florens Verschelde
@fvsch.com

So it's the same as semver-with-many-majors and semver-but-keep-the-major-as-zero-so-that-every-minor-can-be-breaking (already a common practice), but with gaps in the major version to jump to 100, 200, 300. My take: tiny marketing win at the cost of awkward gaps in the versioning scheme, meh.

Florens Verschelde
@fvsch.com

As a user of many packages and libraries, this is also not a problem I have with libraries, and may perpetuate a problem I do have. In my experience, 10 breaking changes are not easier to deal with when spread as 7 majors instead of 1. The only thing that is easier: fewer breaking changes.

0 reposts0 likes

Florens Verschelde
@fvsch.com

Progressive breaking changes have one upside: you can try upgrading major releases one by one. It's still a painful process. Downsides: - flip-flopping changes (v11 changed an API, v16 changed it again, v21 yet again…); - encourages maintainers to give low guidance for breaking changes.

Florens Verschelde
@fvsch.com

Of course maintainers who release many majors don’t HAVE to fall into these traps. But being able to release breaking changes often and in small increments allows hiding the extent of the practical instability of the software. I treat projects releasing 2+ majors a year as a red flag.