3 ms·
Using semver is a promise that if you make a backwards-incompatible change you will update the major version. That's entirely separate from any promise, or sta
by mjw1007 5y ago
Using semver is a promise that if you make a backwards-incompatible change you will update the major version.
That's entirely separate from any promise, or statement of intent, that you might want to make about whether you're hoping to make backwards-incompatible changes rarely or frequently.
Teaching people that they should consider incrementing the major version as indicating a failure isn't going to be helpful.
In practice, given the way semver is defined, if this idea catches on I fear the main effect will be to increase the number of projects that never choose to declare they're version 1.0.
- mjw1007 5y agoMore concretely, scrolling up I see that the tweeter says their threshold for declaring 1.0 is when they « feel that the API will only need to be extended in a backwards compatible way. When taking care not to break people's code is not a burden. » I don't think that's the general understanding we should be aiming for. Rather I think a better threshold (and the one implicit in semver's definition) is to declare 1.0 when the API is stable enough that you're willing to go to the effort of tracking whether the changes you're making are backwards-compatible. Otherwise we're discarding useful information in the meantime.
- simonw 5y agoSo in your model 1.0 is the point at which you start writing proper release notes? I'm not keen on that. During my 0.x period I still want interested third parties to try out and use my code, which means I need to give them good release information to help them help me test everything out.
- mjw1007 5y agoYou can start writing release notes any time you like. The idea of semver was that you use the version number to encode compatibility information, and stop using it as a vague indication of the maturity of the project or the size of the changes in a particular release.