3 ms·
> The date is not informative. It’s not supposed to be informative. It’s not supposed to be parsed. It’s a version identifier. The date is much better than a c
by orf 2y ago
> The date is not informative.
It’s not supposed to be informative. It’s not supposed to be parsed. It’s a version identifier. The date is much better than a commit hash or an opaque number for this.
Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not.
If it’s not compatible, it’s a new version.
Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you.
> That doesn't mean SemVer is inappropriate. It just isn't going to help much.
Irrelevant.
> Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer
Totally irrelevant.
- wakawaka28 2y ago>Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not. Not true. You can be compatible with all APIs, adding no new features; you can add new features; and you can break existing features. These are the levels that SemVer can communicate. This makes as much sense for a web API as a binary library. >Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you. What all 3 of them? A vast majority of people prefer SemVer even if they detest the work that it generates. It's like a form of documentation.
- orf 2y agoAssigning semver versions to deployments makes about as much sense as your replies. Which is why nobody does it. You don’t get it, seemingly by choice at this point. Good luck with that.
- wakawaka28 2y agoYou don't version the deployment, you version the thing being deployed. Lots of people use SemVer for web APIs. I think you clearly don't get why it is superior to TrunkVer. Good luck with that.