Hi Mahmoud! A colleague at the next desk just noticed that https://calver.org throws up a security interstitial on Firefox Nightly because of the forthcoming TLS 1999.01 1.0 deprecation. To keep the calver incantations secret and safe, would you mind upgrading to TLS 2008.08 1.2? https://ssl-config.mozilla.org/ can help generate some config copypasta.

Typo in CalVer Scheme Section

In the "Scheme" section of the CalVer website (https://calver.org/#scheme), there's a typo in the description of the "0Y" format specifier.

Currently, it reads: "0Y - Zero-padded year - 06, 16, 106".

However, the example "106" is inconsistent with the intended format and might cause confusion for users. It should be corrected to "16" to align with the expected output of zero-padding the year.

I think it's better to have multiple languages translated. I just browse the folder structure and found nothing about internationalization. So could you add support for it?

I could translate it to Chinese Simplified.

See here for example: https://en.wikipedia.org/wiki/ECMAScript#Versions

Or there for the latest version: https://www.ecma-international.org/publications/standards/Ecma-262.htm

As a result it would likely deserve to be listed amongst the "Standards", wouldn't it? 🙂

https://openwrt.org/about/history

• SSL certificate problem: certificate has expired

This relates to PR #31

Looking into this further, it appears that (at least for python) strftime actually goes from 0-52 and not 1-53 and the weeks are not actually always 7 days long:

import datetime as dt

base_date = dt.date(2020, 12, 26)

for i in range(10):
    d = base_date + dt.timedelta(days=i)
    print(d.strftime("%Y-%m-%d  %a  %%W:%W  %%U:%U  %%G-w%%V: %G-w%V"))

2020-12-26  Sat  %W:51  %U:51  %G-w%V: 2020-w52
2020-12-27  Sun  %W:51  %U:52  %G-w%V: 2020-w52
2020-12-28  Mon  %W:52  %U:52  %G-w%V: 2020-w53
2020-12-29  Tue  %W:52  %U:52  %G-w%V: 2020-w53
2020-12-30  Wed  %W:52  %U:52  %G-w%V: 2020-w53
2020-12-31  Thu  %W:52  %U:52  %G-w%V: 2020-w53
2021-01-01  Fri  %W:00  %U:00  %G-w%V: 2020-w53
2021-01-02  Sat  %W:00  %U:00  %G-w%V: 2020-w53
2021-01-03  Sun  %W:00  %U:01  %G-w%V: 2020-w53
2021-01-04  Mon  %W:01  %U:01  %G-w%V: 2021-w01

This has the benefit of avoiding the third issue I mentioned in the PR.

Even with the current ambiguity of WW/0W, they have an impact on
how to interpret the YYYY/YY/0Y which is not explicitly stated.

Starting from yesterday CalVer.org is showing wrong documentation. It is showing "ZeroVer: 0-based Versioning" instead of CalVer itself.

Internet Archive: https://web.archive.org/web/20240412052808/https://calver.org/

'Landed here while googling for "date-based semver". I read / scanned the whole document. When I got to the bottom section, "When to Use CalVer", I found myself wondering if I'd missed something.

Like, what is CalVer, exactly???

calver.org summarizes some projects that use date-based version schemes and discusses some common fields and practices in fairly broad terms, but no attempt is made to describe any one, preferred versioning system. And even the examples provided are at times confusing ("YYYY.MM.DD_MICRO" doens't use "point-separated numbers")

In short, CalVer seems little more than a notation for describing [date-based] version strings. But that doesn't seem all that useful.

Questions it doesn't answer:

• How can I identify a CalVer string?
• What is and is not a valid CalVer string?
• What process should be used to generate a CalVer string?
• Is it expected that CalVer strings be parsable to extract the timestamp? (Not a given, btw.)
• What are the requirements for a CalVer string parser?

(BTW, if the answer to that last question starts with, "first you need to know the format description..." then this document hasn't done it's job.)

In short, what i'm suggesting is that rather than being a hand-wavy collection of possible date-based formats, CalVer should springboard off the research that's already been done, and define a single, canonical format that meets the needs of the community moving forward rather than focusing on legacy versioning systems.

Aside: I think CalVer would benefit by being explicit about the fact SemVer is a well-established thing, and that CalVer strings MUST be SemVer compliant. [Edit: Upon further consideration, I've concluded this is just a terrible idea. SemVer and CalVer are just too at odds semantically for this to be viable.]

Hello from New Zealand,

The cert has expired as of about 3am. I presume it's a similar issue as #14 of the server not getting the new cert.

I think the calver.org homepage would really benefit from some clear examples.

There are some in the projects mentioned, but having a section with some examples and explanations how they break down into calver components would be helpful I think.

So I'm trying to validate release versions for youtube-dl, but I'm a little lost how both 2020.06.16.1 and 2020.06.16 are valid versions. Does YYYY.0M.0D_MICRO match both or does it need some other notation?

The current example with Microsoft Windows shows 95, 98, 2000 - but Microsoft hasn't used this scheme in, well, 18 years now.

However - they are using CalVer to describe their updates to Windows 10! See
https://www.microsoft.com/en-us/itpro/windows-10/release-information
https://support.microsoft.com/en-us/help/4099479/windows-10-update-history

Where the version number (major update) uses the format YY0M, giving examples like "Windows 10 version 1703"

We are using CalVer for our documentation as it relates to the legal updates.

You can find the omnibus documentation here: https://freight-chain.github.io/obm/

2019.12 is the authoritative version, meaning in use.

2020.05.04 is the version that is being written today.

Thanks

• sam

Tesla also seems to be doing this, but i'm not 100% sure what the later numbers are.

Latest version right now is 2019.40.50.7, where 2019 is the year and 40 the week of the year. The 7 is patch/bugfix. Not sure about the 50

https://teslafi.com/firmware/

Hi,

I would like to thank to the maintainers of the calver.org since it helped me a lot while writing node-calver. Personally I use calendar versioning in my frontend apps and decided to wrote this utility to automate release numbering process. (and now will help many more js developers) Please let me know if you see any implementation issues if you have a chance to look at it.

I also would like to see a clients section in the website calver.org (apart from users) since there are many implementations across different programming languages. I saw libraries like pycalver for example. This section may make visitors transition from semver (or nothing) to calver easier. I know some developers find calver is more reasonable in some of their projects but they may not transition because of the vast semver community.

According to their main site

Currently our dev repository is taken down due to DMCA takedown notice by RIAA.

pip has switched to calver: https://pip.pypa.io/en/stable/news/

• Minor - The second number in the version. 7 is the most popular
  minor version of Python.

^ Such a claim is not aging well, and also complicating matters since 3.7 is current now. Consider changing to a different example?

https://calver.org/

Mediainfo has adopted Calver from v17.10.

https://github.com/MediaArea/MediaInfo/releases/tag/v17.10

Version scheme is now YY.MM (year dot month, 2 digits each)

I think this versioning scheme should contemplate breaking changes.

A very important feature I see in today's common approaches such as semver is that they reflect the breaking changes in their numbering scheme. However, I see there is nothing similar stated in this specification. Shouldn't it be contemplated?

I would be concerned if I have several dependencies using this scheme and I want to update them. Will certain updates break my code? I will have to check and remember each documentation to find which ones break compatibility (for instance, twisted states that the first two numbers indicate the API compatibility).

I would like to see this spec address use-cases where versioning granularity on the order of 1-second might be needed.

For example, the use case I have is on my npmgraph.js.org site. I allow users to upload package.json files that may or may not have a version. If the case version is missing, I need to assign one. Thus, a date-based version is the obvious choice. However users may upload multiple files within minutes or even seconds of one another. So I'd like version strings that have a reasonable chance of being unique at that level of granularity.

FWIW, the solution I've come up with - that I don't see addressed anywhere in the spec - is to use the semver "rerelease" field to hold the # of seconds in the day. Specifically, I intend to use version strings of the form [full year].[month].[day of month]-[seconds in day] [full year].[day of year].[seconds in day]

[Edit: 'Just realized that the prerelease field of semver is not actually appropriate for holding seconds. My understanding of semver is that the prerelease field should indicate the anticipated version. I.e. it should follow the same form as the the normal (pre-hyphen) fields, but provide the expected version upon release. Given the nature of date-based versioning, that ends up being problematic.... 'basically requires being able to see into the future.]

Current release is 21.7, released in july of 2021. First release was in January 2015, 15.1.

minor patches increment after release, so 21.7.1 came out a few weeks back.

KDE Frameworks (libraries) and KDE Plasma (desktop environment) use traditional major.minor version numbers, but applications use yy.mm versions. For example Dolphin. And the most recent release announcement: https://kde.org/announcements/releases/2020-12-apps-update/

Under your convention I would expect 0Y to be a two digit year with leading zero, e.g. year 2006 --> 06 and year 2016 -> 16.

It would be sensible to restrict this to 2000 to 2099 only to avoid ambiguity, or define year 2123 --> 123 here?

e.g. We could then describe this versioning scheme as MAJOR.0Y.0M.0D:
https://ics.hutton.ac.uk/tablet/download-tablet/
https://ics.hutton.ac.uk/tablet/download-tablet/tablet-release-notes/

The good thing about standards is that there are so many to choose from. /Andrew S. Tanenbaum

Reading the docs here, I couldn't help but remember Tanenbaum's famous statement.

Ubuntu - YY.0M.MICRO
Twisted - YY.MM.MICRO
youtube_dl - YYYY.0M.DD
pytz - YYYY.MINOR
Teradata - YY.MM.MINOR.MICRO
Unity - YYYY.MINOR.MICRO
pip - YY.MINOR.MICRO
PyCharm - YYYY.MINOR.MICRO
OpenSCAD - YYYY.0M 
fusefs-ntfs - YYYY.MM.DD_MICRO
certifi - YYYY.MM.DD
boltons - YY.MINOR.MICRO

Seriously, what the &$!#%?

Please publish a grammar defining what constitutes a valid CalVer. As is abundantly clear from the above, such an important decision can't be left up to individual projects. Apart from restoring some sanity, it'll also help tools like the one I wrote (jsemver).
SemVer 2.0 BNF grammar for reference: https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions

It is also import to define precedence rules. Is 2020 greater, smaller or equal to 20? What characters are allowed in each version segment? Are numeric segments compared alphabetically or numerically? To my knowledge, none of these questions are answered by https://calver.org.

The Let's Encrypt certificate for https://calver.org/ expired yesterday.

Looking at pytz example, it's listed as YYYY.MM but that's not really right. You may also note the release history dates are not corresponding with months: https://pypi.org/project/pytz/#history

I emailed pytz maintainer directly, and it is actually based off of the IANA release files https://data.iana.org/time-zones/releases/ which use an incrementing letter suffix. That's not compatible for python version numbering, so pytz change it to an integer

e.g. Olson database 2018c (dated January, third Olson release in 2018) would correspond to pytz 2018.3

Hi @mahmoud,

Another one for the list: conda switched to CalVer.

Cheers
Felix

Docker Engine starting from 17.03 is calver-ed.
1.13 and earlier versions are not.