SQLAlchemy author here. The critique of "Backbone" and the original quoted author's note at https://github.com/jashkenas/backbone/issues/2888#issuecomment-2907

SQLAlchemy author here. The critique of "Backbone" and the original quoted author's note at https://github.com/jashkenas/backbone/issues/2888#issuecomment-29076249 https://github.com/jashkenas/backbone/issues/2888#issuecomme... expresses an issue that SQLAlchemy has as well. A fine-grained development library has a ton of "surface area". Like Backbone, a large portion of our bugfixes necessarily infringe upon some previously undefined behavior that will now "break" for people who relied upon that. If SQLAlchemy were pure semver, we too would be at SQLAlchemy 48.0.0, the third digit for us would usually be fixed at "0" and mostly useless, and we would have no way to distinguish between a "major feature release with semi-breaking changes and removal of things that have been deprecated for years" which is what we normally have in our 1.2, 1.3, 1.4 etc. vs. a "major release with significant backwards-incompatible changes" which is what we will have in SQLAlchemy 2.0. We necessarily include extremely detailed change documentation for a 1.x to 1.y release and our versioning system is described in great depth at https://www.sqlalchemy.org/download.html#versions https://www.sqlalchemy.org/download.html#versions . I didn't provide an easy word like "romantic" for this website to mock but we're doing essentially the same thing AFAICT. When Jeremy says "This allows folks, immediately upon hearing about a new release, to get a rough sense of its scope.", that is exactly what we are doing as well when we are suddenly calling an upcoming release "2.0". The scope is dramatically broader than the scope in which we move from 1.x to 1.y. It's fun for semver purists to make clever (and definitely funny) websites mocking this need but that does not change that fact that semver does not work for every kind of project.