CalVer: Calendar Versioning

#1

Post by tosh » Mon, Jan 06, 2020, 9:43 AM UTC

CalVer: Calendar Versioning
calver.org

Re: CalVer: Calendar Versioning

#2

Post by Deukhoofd » Mon, Jan 06, 2020, 10:45 AM UTC

You should probably look at updating your TLS. TLS 1.0 will be deprecated in 2 months.

Re: CalVer: Calendar Versioning

#3

Post by wodenokoto » Mon, Jan 06, 2020, 11:04 AM UTC

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.

Re: CalVer: Calendar Versioning

#4

Post by regularfry » Mon, Jan 06, 2020, 11:29 AM UTC

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.

Re: CalVer: Calendar Versioning

#5

Post by skrebbel » Mon, Jan 06, 2020, 11:32 AM UTC

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

Re: CalVer: Calendar Versioning

#6

Post by SlowRobotAhead » Mon, Jan 06, 2020, 11:46 AM UTC

Amazon just adopted this for at least their FreeRTOS releases. 201912.00 is the latest. Handy enough to know how out of date you are - but overall fairly useless because I still need to go check and see what’s been released since. Not to mention some people might flinch if your latest release is 200501.00 even if it’s amazingly complete code.

Re: CalVer: Calendar Versioning

#7

Post by vegardx » Mon, Jan 06, 2020, 11:48 AM UTC

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 major releases and so on.

Re: CalVer: Calendar Versioning

#8

Post by julbaxter » Mon, Jan 06, 2020, 11:48 AM UTC

You should probably consider changing the name. https://translate.google.com/?hl=fr#fr/en/calvaire

Re: CalVer: Calendar Versioning

#9

Post by chrismorgan » Mon, Jan 06, 2020, 11:52 AM UTC

Deukhoofd wrote: post #2

You should probably look at updating your TLS. TLS 1.0 will be deprecated in 2 months.

TLS 1.0 won’t be deprecated in two months’ time, it’s being removed in two months’ time (from at least Firefox, Chrome and Safari; for IE and Edge Microsoft have just said the first half of the year). It’s already deprecated, has been for yonks.

Re: CalVer: Calendar Versioning

#10

Post by lekevicius » Mon, Jan 06, 2020, 11:53 AM UTC

A good 30 minute podcast discussing this topic is Episode #164 "Meaningless Version Numbers" of Under The Radar podcast with Marco Arment and _David Smith.

During this episode Marco explains his decision to switch to YYYY.MINOR.MICRO scheme for Overcast, his podcast player.

https://www.relay.fm/radar/164