Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CalVer: Calendar Versioning

calver.org

Post reply on HN
Print view View original

11–20 of 102 posts

Re: CalVer: Calendar Versioning

#12

Post by chrismorgan »

wodenokoto wrote: post #3

I would have expected D to be short day (1, 2, 3 .. 29,30,31) and DD be zero padded (01,02,03 .. 29, 30, 31) But other than that, I think it is a good idea to try and lay out a common language for the cases described.

Yeah, DD being short day is just wrong by conventional usage.

Re: CalVer: Calendar Versioning

#14

Post by wufocaculura »

skrebbel wrote: post #5

Any opinions on calver vs semver for, say, open source projects or APIs/SDKs?

No strong opinion here, but I see calver as a good fit for a new / rapidly changing project (with yyyymmdd being a both version and snapshot date), or for a software where you don't need semver guarantees about api change - so not for a library or for some important tool that is often scripted.

Or, as described in the project, calver might be good as a release date for a "umbrella projects" - like Ubuntu, or even Windows 10 builds.

Re: CalVer: Calendar Versioning

#15

Post by capableweb »

vegardx wrote: post #7
skrebbel wrote: post #5

Any opinions on calver vs semver for, say, open source projects or APIs/SDKs?

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 ma…

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

Re: CalVer: Calendar Versioning

#17

Post by lioeters »

regularfry wrote: post #4

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.

I'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.

Re: CalVer: Calendar Versioning

#19

Post by regularfry »

lioeters wrote: post #17
regularfry wrote: post #4

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.

I'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-fa…

Yeah, 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.
Post reply on HN