3 ms·
I've done something similar to this in the past, only simpler: "YYYYMMDDXX" where XX is an incrementing index of today's releases. It works well where you've g
by regularfry 7y ago
I've done something similar to this in the past, only simpler: "YYYYMMDDXX" where XX is an incrementing index of today's releases.
It works well where you've got no commitment or requirement to release patches of old versions rather than roll forward. In my experience, that covers most internal software, where semver is overkill.
- lioeters 7y agoI've used the same format as you mentioned, usually for non-public-facing modules. Sometimes it starts with "YYYYMMDD", then "YYYYMMDD.XX" if needed. Every version potentially breaks backward compatibility, regardless of versioning standard (semver, calver, or anything else). It's the responsibility of the module consumer to have tests and ensure its own functioning. I do find semantic versioning useful for public-facing modules/interfaces, to indicate (or infer from the consumer side) the intended compatibility. In practice, though, sometimes patch versions break things, or major version upgrades work fine without any changes. So the consumer still needs to be responsible for ensuring compatibility - not much different than calendar versioning.
- regularfry 7y agoYeah, that was my realisation. Semver ends up being a lie often enough, and back-ported patches happen rarely enough, that it ends up being engineering theatre more often than not.