4 ms·

Semantic versioning tells you a lot about the state of a release. Is it supposed to break backwards compatibility or does it just add new or patch existing back

Semantic versioning tells you a lot about the state of a release. Is it supposed to break backwards compatibility or does it just add new or patch existing backwards compatible functionality? I think that sort of stuff is more important than on what day the release was made. For an API it seems like a no-brainer to use semantic versioning, makes it easier to document feature deprecation, like supporting latest two major releases and so on.

capableweb 7y ago
Something like CalVer forces you to consider every version breaking and puts the responsibility on you to ensure compatibility with your project. SemVer puts the responsibility on the maintainer to assume how users are using the library. I think by now we've learned that even though SemVer was a good idea, people are people and they are gonna eventually fail at setting the version correctly, making your assumptions broken
- vegardx 7y ago
  That can be said about any versioning scheme. The idea that making things inconvenient suddenly makes people do the right thing is pretty naive, if you ask me. Semantic versioning lets the user decide.
- rtpg 7y ago
  Semver still communicates intents pretty well. Well run projects will even roll back changes that ended up being semver incompatible Treating every patch release of Django like a major release would be a major waste of time compared to “assume Django maintainers have a good idea of how things are used, and rely on automated test suite”
  - capableweb 7y ago
    > Semver still communicates intents pretty well. Well run projects will even roll back changes that ended up being semver incompatible That sounds either worse. Software releases should be immutable, so no changing existing versions. And also, if X.Y is incompatible (because they screwed up the versioning, as in your example), X.Z should also be incompatible (according to semver), otherwise you break semver twice instead of just once... > Treating every patch release of Django like a major release would be a major waste of time Yeah, I guess computing time. If you manually testing each dependency update, your doing something wrong. This should be automated to such level as you feel comfortable stuff is working by just running the tests.
- marcosdumay 7y ago
  Using a library puts the responsibility on you to ensure compatibility. With SemVer the library maintainer tells you "here, let me help you". With CalVer the maintainer says "fuck that, I'm out". None changes your responsibility.

capableweb 7y ago

Something like CalVer forces you to consider every version breaking and puts the responsibility on you to ensure compatibility with your project. SemVer puts the responsibility on the maintainer to assume how users are using the library. I think by now we've learned that even though SemVer was a good idea, people are people and they are gonna eventually fail at setting the version correctly, making your assumptions broken

vegardx 7y ago
That can be said about any versioning scheme. The idea that making things inconvenient suddenly makes people do the right thing is pretty naive, if you ask me. Semantic versioning lets the user decide.
rtpg 7y ago
Semver still communicates intents pretty well. Well run projects will even roll back changes that ended up being semver incompatible Treating every patch release of Django like a major release would be a major waste of time compared to “assume Django maintainers have a good idea of how things are used, and rely on automated test suite”
- capableweb 7y ago
  > Semver still communicates intents pretty well. Well run projects will even roll back changes that ended up being semver incompatible That sounds either worse. Software releases should be immutable, so no changing existing versions. And also, if X.Y is incompatible (because they screwed up the versioning, as in your example), X.Z should also be incompatible (according to semver), otherwise you break semver twice instead of just once... > Treating every patch release of Django like a major release would be a major waste of time Yeah, I guess computing time. If you manually testing each dependency update, your doing something wrong. This should be automated to such level as you feel comfortable stuff is working by just running the tests.
marcosdumay 7y ago
Using a library puts the responsibility on you to ensure compatibility. With SemVer the library maintainer tells you "here, let me help you". With CalVer the maintainer says "fuck that, I'm out". None changes your responsibility.