
Calendar Versioning - dmoreno
https://calver.org/
======
indentit
I was interested to see a more formal definition of calendar versioning than
I've come across before, until I saw that it refers to `DD` for short day
while `0D` is zero padded - which goes against all date formatting
specifications ever... `DD` should be zero-padded and a single `D` unpadded...

~~~
xapata
Or how about `d` vs `D`?

IEEE standard.

[http://pubs.opengroup.org/onlinepubs/009695399/functions/str...](http://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html)

------
amelius
Are they trying to make this as obscure as possible? After reading the top of
the scrollable page, I still couldn't understand what a CalVer version string
looks like.

Also, I think version strings should contain information about compatibility,
not just about time.

~~~
mderazon
> Also, I think version strings should contain information about
> compatibility, not just about time.

I find semver useful for libraries but mostly meaningless for projects that
have no dependents like a web server or a website.

~~~
dzek69
Web server version may talk about supported config syntax, supported out of
the box features and modules. Anything not backward compatible should bump
major version.

Not much project would benefit from this kind of versioning. Only websites,
desktop apps with no config files, etc.

------
noir_lord
I decided to use calendar versioning for our companies internal ERP system
since it makes it explicit to end users when a new release has been rolled out
(2018-06-06.1 is more human than #9b867341 or 27.1.321.1).

No reason other than that.

I also change the background image of the login page on 'major' releases where
significant new features are added as a subtle visual cue that users should go
check out the change log.

It's often the little touches that have a disproportionate impact on user
engagement.

~~~
JackFr
> 2018-06-06.1

What is the trailing 1? Are you doing multiple releases per day? Is an
emergency bug fix release on June 8th 2018-06-08.1 or 2018-06-06.2?

~~~
noir_lord
Yep, multiple releases per day if there is a nasty bug/regression.

It's rare but it happens.

I chose to start at .1 and not .0 because users don't really get 0-based
releases (at least mine don't).

------
paulddraper
I'm surprised to see some of the most popular software of all time not be
mentioned: Windows and Microsoft Office.

Also, for a more technical audience, the C, C++, and EcmaScript
specifications.

~~~
wodenokoto
Windows goes something like this (there's no real straight line, feel free to
add your own progression):

3.11, 95, 98, ME, 2000, XP, Vista, 7, 8, 10

I wouldn't call that a pattern.

~~~
ocdtrekkie
Windows 10 versions are CalVer. The most recent release was 1803. Previous
versions were 1709, 1703, 1609, etc.

------
sytse
At GitLab we just bump the minor version every month. And when there is a
breaking change we bump the major version. The advantage is that semver is
well understood and we can communicate breaking changes. The disadvantage is
that you need to look up what version was released when.

~~~
jamietanna
Do subcomponents ie Gitaly have their own versions? Or does it match GitLab
proper?

------
pavel_lishin
> _0Y - Zero-padded year - 06, 16, 106_

It seems very odd, to me, to make this a variable-length field. If you're
planning out to 2106, why would you not use a full length year? This
particular bike shed should clearly be blue.

~~~
mhashemi
Added by user request 1 hour ago:
[https://github.com/mahmoud/calver/issues/5](https://github.com/mahmoud/calver/issues/5)

It's more for the past (06) than for the future.

------
progval
CalVer is also nice for mature projects that don't get new groundbreaking
features because they don't need them.

I wrote a small piece of code in my project's setup.py [1] that computes the
version number from the timestamp of the last git commit. It's very useful
because it removes the need to make a commit for the sole purpose of updating
the version number. (I also had issues at the time there were multiple forks
of this software, merging each other, causing conflicts on the version
number.)

[1]:
[https://github.com/ProgVal/Limnoria/blob/testing/setup.py#L5...](https://github.com/ProgVal/Limnoria/blob/testing/setup.py#L54-L64)

------
ams6110
I like versioning schemes that imply something about the amount of change in
that specific version, not just its position on a timeline.

~~~
progval
For some projects, "amount of change" is either hard to quantify, or mostly
constant between two versions (eg. Ubuntu, Firefox, Chromium)

------
twic
Where i work, most of our libraries have a version number with a single
component, which we increment with each release. So i recently released a new
version of AdminTools, taking it from 37 to 38. Should i go and register
SerVer.org so i can tell the world about this incredibly trivial scheme?

~~~
geofft
Yes. I've got some questions about your incredibly trivial scheme:

* Do users declare a dependency on "= 37", or ">= 37"? (Or do they have the option of either?)

* How do you push backwards-compatible changes like bugfixes? Is the rule that every new release is a new version number?

* If you do the >= thing, do you automatically take the newest compatible dependency or the oldest possible one (vgo-style)? Do you run tests on reverse dependencies when dependencies are updated?

* Are you allowed to have diamond dependencies, e.g., A depends on B and C, B depends on AdminTools 37, and C depends on AdminTools 38? Do you resolve that with a single copy of AdminTools, or two?

~~~
syrrim
I have one single question: how does calver solve any of these problems?

~~~
geofft
Differently in different projects, but usually adopting CalVer is a sign that,
unlike with SemVer, you're not using the version number to connote backwards
compatibility. Code that continues to be accessible via the same
path/name/etc. is _always_ backwards-compatible (i.e., if a consumer
application would compile or run fine on a newer version without errors, there
aren't hidden semantic changes). If you need to make a backwards-incompatible
change, you handle it in some means other than the version number, usually
either by renaming the project, the import path, or the function.

Looking at the example CalVer projects: Ubuntu follows this model because it's
the model of basically all UNIX distributions, that a particular command name
doesn't change meaning / API without either a deprecation cycle or an explicit
action from the sysadmin. If a command changes incompatibly (e.g., Python 2 to
Python 3), it gets a different name (e.g., /usr/bin/python to
/usr/bin/python3). If a library changes incompatibly, it either uses symbol
versioning infrastructure to provide old and new versions of the function
(e.g., fmemopen@GLIBC_2.2.5 is now provided by libio/oldfmemopen.c, and the
fmemopen@GLIBC_2.22 implementation, which fixes tons of bugs and drops
questionable features, is only visible to programs compiled on a system with
glibc 2.22 or newer), or the library itself has a new filename (e.g., at some
point libcurl.so.3 became libcurl.so.4). Therefore, code that compiled and ran
fine on, say, Ubuntu 16.04 should generally be expected to compile and run
fine on Ubuntu 18.04, or less commonly, not run at all with a clear error up
front about the specific missing functionality.

Twisted, youtube-dl, and pytz follow a similar model. Code written against
them years ago should generally continue to work; the version number provides
information on _new_ features, not on deprecations.

Teradata UDA is different, but it follows the underlying CalVer philosophy of
breaking changes being something to avoid. (But it uses a year and month to
indicate an API compatibility level, which isn't how the rest of the CalVer
projects use dates.)

So the answers to my bullet points for CalVer are generally ">=", "Rename the
functionality, do not ever redefine an existing name", "Newest compatible
dependency is fine and you should definitely have integration tests," and
"Diamond dependencies to different versions aren't a problem, diamond
dependencies to different names e.g. libcurl.so.3 and libcurl.so.4 are
discouraged but should work".

------
mkj
For a mature program (not a library) I like using a combination year.counter.
No semantic meaning at all apart from monotonous improvement, and you can tell
how old a version is.

2017.75, 2018.76, 2018.77, 2019.78 etc

------
missionsix
Has anyone successfully transitioned from SemVer to CalVer? Especially with a
large customer base who is familiar with the the major product versions but
gets confused with the minor/patch variants and what’s included ?

I’m interested in your war stories, pm me.

~~~
mhashemi
Here was a recent high-profile but somewhat contentious transition:
[https://github.com/pypa/pipenv/issues/2191](https://github.com/pypa/pipenv/issues/2191)

The key here was that the rapid pace of the project kept breaking various user
segments' expectations about semantic versioning.

------
teddyh
A version number which includes the date it is released is more common for
development or “snapshot” releases, so you should only use this versioning
scheme if you are fine with people assuming it is in fact that kind of interim
or unofficial release.

~~~
dfee
This is opinion masquerading as fact.

Take for instance Ubuntu - should those releases be considered unofficial?
[no]

How about the python-attrs library - should those be considered interim? [no]

All versioning schemes fail somewhere and CalVer and SemVer (and certainly
others) are not exceptions to this rule. The problem is you’re reducing a ton
of metadata into a human-readable, compact label - and that’s inherently
lossy.

------
tzahola
The bikeshedding is strong in this one.

