NumPy 2.0.0 is the first major release since 2006.
This is an example of a good governing model for open source libraries. Design your public APIs in such a way that there should be no breaking API changes in a short span of time and there should be minimum LTS branches to maintain. It allows industrial projects to catch up with most of your features and documentation. Then years later you finally revisit your legacy APIs, redesign them and move to version 2 while also maintaining backward compatibility. SQLAlchemy is another library that is built right.
I discourage packages which goes from version 1 to version 6+ in a matter of 2 years. It creates too much fragmentation and users are not able to keep up to date with new APIs. High version number should not be seen as an indicator of rapid development.
Basically every 1.x.0 release of numpy had at least some things that a strict interpretation would consider 'breaking changes'. If numpy followed semver, their major version would probably be ~20ish by now.
Don't get me wrong, I agree numpy has a pretty good policy here, but this comment makes it sound way stricter than it actually is