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

91–100 of 102 posts

Re: CalVer: Calendar Versioning

#91

Post by SahAssar »

skissane wrote: post #86
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…

> SemVer gives extremely useful information here to establish how "dangerous" and update might be. I'm doubtful about how useful the information SemVer gives really is. Someone can make massive changes to a package, rewrite half of it from scratch, add huge new features, completely redesign how parts of it are implemented, but if they don't making any breaking API changes the first version segment doesn't increment.…

SemVer is about the public API, it says nothing about test-coverage, internal changes or transient dependencies.

The point of SemVer is to answer "if I trust the authors of this library to be as good or better than me at writing libraries, is it safe to upgrade?". The moment you don't trust the authors of the library to be as good or better than you it sorta breaks apart as a covenant, but it will still show the intent of the author.

So SemVer has problems, but CalVer just shows "I tagged a release at a date".

IMO badly practiced SemVer is better than perfect CalVer simply because I can open an issue of fix something that was broken because of SemVer, but with CalVer I need to live with any breakages regardless of if they were intentional or not.

Re: CalVer: Calendar Versioning

#92

Post by SahAssar »

33degrees wrote: post #30
skrebbel wrote: post #5

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

For APIs, calver can make a lot of sense, as detailed in Stripe’s blog post on the subject https://stripe.com/en-ca/blog/api-versioning

That's just because they keep compatibility basically forever (they build middleware to transform older versions to new ones). If you actually want to remove old versions not so much.

Re: CalVer: Calendar Versioning

#93

Post by eqvinox »

mhashemi wrote: post #84
eqvinox wrote: post #78

Earlier quoted context omitted.

> Why? Why what? (I seriously don't understand what argument you're trying to make in your first paragraph.) > [...] SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always create problems. You're forgetting to ask the question whether this bill of goods is desirable. Considering the environment we have today (frequent security update…

I was only asking why you say it comes crashing down, when the link cites multiple cases of successful parallel version maintenance with a version that is at least partially calendar-based. As far as usability, time is a dimension no developer can escape. We develop software on a schedule and we deprecate it on a schedule. CalVer is tremendously semantic at that higher level. The semantics SemVer clings to suffer eve…

The fix to it coming crashing down seems to be to append another version number, at which point the date code becomes kind of a branch indicator.

Now you have a choice of either incrementing the date code liberally for small releases (e.g. Twisted), or keeping it sticky until you make a major change (e.g. Teradata.)

If you do the former, you're depriving the user (or chain-up developer) of information on how big a particular change was. It might be 20190322 to 20190411 but you merged a huge rewrite. Or it's 20180107 to 20190929 and it's just some fixes. You might as well give your releases alphabetically increasing codenames, same information content there.

On the other hand if you keep it sticky until you make a major change, you're back to making a call whether some change is "major" or not. You might as well use SemVer. If anything, a date code in front of the version number becomes misleading since if you reach a reasonably stable API it'll start getting weirdly old and confuse users.

I also find it funny (and somewhat disingenious) that you assume I never tried calendaric versioning. I use (or suggest) it whenever some project starts or otherwise (e.g. rewrite) goes through an instability period. This generally means version numbers like "0.20190811". When the instability period has passed, it moves to e.g. "1.0" and sticks with SemVer from there. If we start rewriting on top of 2.3, the version number might temporarily be e.g. "2.99.20200105". Exact numbers (and components/dot count) depends on the specific situation.

It's hopefully obvious that all of these versions are something I'd call "alpha" or "internal consumption". (Also means my brain has learned prejudice to distrust any version number with a date code.)

[Edited] P.S.: developers can't escape time, but code can. I recently dug up a project I last touched in 2007, and you know what? I don't even get compiler warnings. It just works. (It's obviously written in a language & ecosystem that affords this possibility — not all of them do.)

Re: CalVer: Calendar Versioning

#96

Post by Sean1708 »

0xffff2 wrote: post #65
Sean1708 wrote: post #38

Earlier quoted context omitted.

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.

My point isn't that it has no downsides, my point is that it would be a far less pressing issue than Y2K was.

Re: CalVer: Calendar Versioning

#97

Post by Xylakant »

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…

> say LibA v3.0.1 vs LibB 1.0.0 – reveals something useful, such as, that LibA has undergone three major revisions, so perhaps it is much more mature than LibB.

It can also mean that LibA messed up their API design twice and had to break BC twice while LibB worked diligently to provide a design that nailed it at first try or spent years in 0.XX territory and only called it stable when they were certain it's stable.

I don't consider SemVer useful to compare the maturity of software components. It's not a statement about that. It's useful to get a grip on how hard it's likely to be to go from one version to the next one.

Re: CalVer: Calendar Versioning

#98

Post by thebeardisred »

skrebbel wrote: post #5

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

At CoreOS (circa 2013+) we used something ideologically similar to CalVer but with tweaked semantics.

As per our documentation (https://coreos.com/releases/): CoreOS Container Linux version numbers are determined by the number of days since the CoreOS epoch, July 1, 2013, at the time the release is built for the Alpha channel.

There were definitely challenges but it provided a rigorous method to ensure monotonically increasing values. It had a useful side effect of getting people out of the habit of "caring" about which version they were running and instead allowed us to focus on simply "being up to date."

Re: CalVer: Calendar Versioning

#99

Post by joshspankit »

mhashemi wrote: post #87
joshspankit wrote: post #83

The unfortunate truth about calendar versioning is that it pushes devs and clients toward “freshness” instead of quality. Same issue that we have in Apple’s design department: change for the sake of change.

People like bigger numbers and newer releases regardless of exact versioning scheme. SemVer makes that situation worse, by requiring a bigger major release to break some part of the API. Other failure modes detailed here: https://sedimental.org/designing_a_version.html

Definitely a fair point. I think we’ve all seen at least one of our favourite pieces of software fall in to this when the company needed another major release to bring in funds.

Re: CalVer: Calendar Versioning

#100

Post by capableweb »

rtpg wrote: post #23
capableweb wrote: post #15

Earlier quoted context omitted.

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

Semver still communicates intents pretty well. Well run projects will even roll back changes that ended up being semver incompatible Treating every patch release of Django like a major release would be a major waste of time compared to “assume Django maintainers have a good idea of how things are used, and rely on automated test suite”

> Semver still communicates intents pretty well. Well run projects will even roll back changes that ended up being semver incompatible

That sounds either worse. Software releases should be immutable, so no changing existing versions.

And also, if X.Y is incompatible (because they screwed up the versioning, as in your example), X.Z should also be incompatible (according to semver), otherwise you break semver twice instead of just once...

> Treating every patch release of Django like a major release would be a major waste of time

Yeah, I guess computing time. If you manually testing each dependency update, your doing something wrong. This should be automated to such level as you feel comfortable stuff is working by just running the tests.

Post reply on HN