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

61–70 of 102 posts

Re: CalVer: Calendar Versioning

#61

Post by eqvinox »

This comes crashing down in a nice mudslide the exact moment you start maintaining an older stable release for fixes while also progressing on a newer version. If anything, date codes are useful as later version number component, e.g. 4.1.0.191220.

Also, the "When to use" section is getting things quite wrong:

  Does your project feature a large or constantly-changing scope?
    Large systems and frameworks, like Ubuntu and Twisted.
    Amorphous sets of utilities, like Boltons.
Wrong question - relevant is: "is your project the top end of the dependency chain?"

  Is your project time-sensitive in any way? Do other external changes drive new project releases?
    Business requirements, such as Ubuntu's focus on support schedules.
    Security updates, such as certifi's need to update certificates.
And both of these are actually made much harder by calendaric versioning. Administrators are already reluctant to update software for fear of breaking things. SemVer gives extremely useful information here to establish how "dangerous" and update might be. With date code versions, the admin is forced to dig through change logs, which costs time they probably don't have, so they'll just not update.

Re: CalVer: Calendar Versioning

#62

Post by eddieh »

plainOldText wrote: post #45

I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning. Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31 . These versions tell you nothing about the projects except their release dates. On the other hand, semantic versioning (w…

Anytime I see calendar versioning I assume one or more of the following are true about the project/package:

- it is poorly maintained

- the authors are being lazy

- it's some kind of unofficial patch or build

- marketing has taken over

- nostalgia (for Windows 95?) or imitating turn of the century project marketing

I don't think there's a good reason to ever deviate from the simple [$MAJOR_CHANGES].[$NEW_FEATURES].[$PATCH]. I don't even think it needs to be formally specified (looking at you SemVer). Simple 3-tuple versioning is almost universally understood. Why fix what isn't broken?

Re: CalVer: Calendar Versioning

#63

Post by ppseafield »

avereveard wrote: post #59
elsurudo wrote: post #48

Earlier quoted context omitted.

Not sure if you should rely on SemVer for maturity estimates either, though. I guess it can be one signal, but I wouldn't say a very useful one.

yeah is 1.7 a very stable 1.x or a very immature 2.x? what is 0.7 then? and 2.0? can't answer one and the other consistently. it's great for compatibility level, and that's that.

Indeed, React got to version 0.14.x before the major number became 15 after a total of three years since the first public release.

Re: CalVer: Calendar Versioning

#64

Post by gregmac »

I like that there's a standard page for this for reference, but I disagree with some of the use cases.

I think it makes sense in a few cases:

* Umbrella-type projects, such as an Operating System, with Ubuntu being a great example.

* Time-dependent projects (where it's more about data), such as tzdata, certificates, tax rates, etc.

* Constantly-changing APIs

I disagree with some of the projects listed, such as Unity and boltons (more on that below).

----

I think the trick to this working well is that at least one of the following must be true:

* You never break backwards compatibility. For example: tzdata, certificates

* There has to be another way to check dependencies. For example: the individual package versions used within Ubuntu

* Release notes (and upgrade notes) need to be really good. For example: include an "upgrade guide" that explicitly calls out breaking changes and how to fix them; summarize the major changes over time; make sure they're digestible by someone who is updating from a few major versions from a couple years ago (without having to read through each incremental guide).

----

Unity is actually a good counter-example to CalVer as it doesn't follow any of these rules. A quick search comes up with breaking changes in at least 2019.2.5, 2019.1.0 and 2018.3.0 [1]. To make things worse, they release frequently -- if I'm updating from say, 2018.2.0, there have been 85 (!) releases since then. The release notes are very detailed and on individual pages so it would be a multi-hour effort to read through to even figure out how complex it'll be to upgrade. This is especially annoying if I'm updating in a hurry to get an important security fix. At least with SemVer I could focus on the major releases.

[1] https://unity3d.com/unity/whats-new/2019.2.5, https://unity3d.com/unity/whats-new/2019.1.0, https://unity3d.com/unity/whats-new/unity-2018.3.0

Re: CalVer: Calendar Versioning

#65

Post by 0xffff2 »

Sean1708 wrote: post #38
mfer wrote: post #32

Earlier quoted context omitted.

You don't need to wait for Y3k. 21xx is enough to cause duplication. There is software still running from over 50 years ago. I'd imagine new releases have come out. But, this may be a legit problem some day.

The upside being that releasing a new version with a different version scheme isn't a time-sensitive task, the old version isn't going to stop working just because the new version number wouldn't be valid.

Changing versioning schemes comes with its own set of problems. There is rather famously no "Windows 9" because enough people detected Windows 95/98 with the equivalent of a regex looking for "Windows 9*" that Microsoft thought it might be a problem.

Re: CalVer: Calendar Versioning

#66

Post by BubRoss »

eqvinox wrote: post #61

This comes crashing down in a nice mudslide the exact moment you start maintaining an older stable release for fixes while also progressing on a newer version. If anything, date codes are useful as later version number component, e.g. 4.1.0.191220. Also, the "When to use" section is getting things quite wrong: Does your project feature a large or constantly-changing scope? Large systems and frameworks, like Ubuntu an…

Why not use two date codes, the release date and the update date?

Re: CalVer: Calendar Versioning

#67

Post by tasn »

aidenn0 wrote: post #58
tasn wrote: post #43

Earlier quoted context omitted.

I also wish all of my data was version controlled, which is why when I created EteSync[1] I made sure to include a full change history. Check it out, I think it's exactly what you're looking for, and it's fully open source, so you can host in on-site if your company requires that. https://www.etesync.com

Can that do shared calendars? (I know that's technically challenging with ETE encryption). If it does, I will drop my self-hosted davical for it in a heartbeat.

Yeah, it does. You just need to manually verify each member you add to make sure they are trusted (or alternatively just YOLO).

Re: CalVer: Calendar Versioning

#68

Post by emptysea »

timeattack wrote: post #26

I'm using similar versioning for pre-build packages, but it's extended with commit information to 1:1 mapping to the source tree: local date=$(git log -1 --format="%cd" --date=short | sed s/-//g) local count=$(git rev-list --count HEAD) local commit=$(git rev-parse --short HEAD) echo "$date.${count}_$commit" Example result: 20191121.68_84f90ff It provides user about general information about when program was updated…

FYI, using `local foo=$(some-command)` does not actually make the variable local.

    main() {
      local count=$(git rev-list --count HEAD)
      echo $count
      foo
    }
    
    
    foo() {
      echo $count
    }
    
    main
prints:

2282 2282

Re: CalVer: Calendar Versioning

#70

Post by pests »

aidenn0 wrote: post #57
plainOldText wrote: post #45

I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning. Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31 . These versions tell you nothing about the projects except their release dates. On the other hand, semantic versioning (w…

High major numbers with semver is a "stay far far away" signal for me; each major increment is a non-backwards compatible change.

Major numbers don't always match actual number of major releases. For example Java skipped from 1.4.x to 5.0.0 and React from 0.14.x to 15.0.0.
Post reply on HN