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

71–80 of 102 posts

Re: CalVer: Calendar Versioning

#71

Post by eqvinox »

BubRoss wrote: post #66
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?

For starters, that's a pretty long version number, making it difficult to see at a glance what the relation is. One date (or two for comparing) is something humans are trained to handle, two dates (or four!) not so much.

Also, now you just have SemVer with really large version numbers.

Re: CalVer: Calendar Versioning

#72

Post by minitech »

emptysea wrote: post #68
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

Sure it does, that’s just how locals work (in bash and similar). Try printing it after `main` with and then without `local`.

Re: CalVer: Calendar Versioning

#73

Post by mhashemi »

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? The version number is determined by the original release date, and after that it's just a normal version number. Pretty sure the Teradata library linked does basically that. Python's manylinux standard is another example.

The whole point of CalVer as an alternative is that 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.

More discussion here: https://sedimental.org/designing_a_version.html

Re: CalVer: Calendar Versioning

#74

Post by mhashemi »

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…

A short list of SemVer's failures to communicate project maturity: https://0ver.org/

Re: CalVer: Calendar Versioning

#75

Post by mhashemi »

chrismorgan wrote: post #9
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.

You're quite right, and this site is being migrated this week. I was going to do it this morning, but there was a traffic spike for some reason? :)

Re: CalVer: Calendar Versioning

#76

Post by emptysea »

minitech wrote: post #72
emptysea wrote: post #68

Earlier quoted context omitted.

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

Sure it does, that’s just how locals work (in bash and similar). Try printing it after `main` with and then without `local`.

Ah my mistake

Anyways there are some more subtle caveats discussed in this blogpost I was trying to remember:

https://jmmv.dev/2018/03/shell-readability-local.html

Re: CalVer: Calendar Versioning

#77

Post by JoshTriplett »

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…

For several packages I maintain, the version number is just $(git rev-list --count HEAD). One monotonically increasing number, nothing else.

(This is for software that does not do updates to old releases. If you do updates to old releases, you need an additional version number component for that.)

Re: CalVer: Calendar Versioning

#78

Post by eqvinox »

mhashemi wrote: post #73
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? The version number is determined by the original release date, and after that it's just a normal version number. Pretty sure the Teradata library linked does basically that. Python's manylinux standard is another example. The whole point of CalVer as an alternative is that SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always c…

> 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 updates, huge dependency chains, interconnected systems), I'd say it's not just desirable but straight up necessary. People should be able to blindly update. They need to be able to, because users are not developers and updates need to be made as accessible as possible in order to propagate and proliferate as quickly as possible.

What we need is better testing and release engineering to get SemVer right, not defining the problem away by ditching a layer of usability.

Re: CalVer: Calendar Versioning

#79

Post by marcosdumay »

capableweb wrote: post #15
vegardx wrote: post #7

Earlier quoted context omitted.

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

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…

Using a library puts the responsibility on you to ensure compatibility.

With SemVer the library maintainer tells you "here, let me help you". With CalVer the maintainer says "fuck that, I'm out". None changes your responsibility.

Re: CalVer: Calendar Versioning

#80

Post by paulddraper »

eqvinox wrote: post #71
BubRoss wrote: post #66

Earlier quoted context omitted.

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

For starters, that's a pretty long version number, making it difficult to see at a glance what the relation is. One date (or two for comparing) is something humans are trained to handle, two dates (or four!) not so much. Also, now you just have SemVer with really large version numbers.

The release date portion may be abbreviated (assuming no more than one major release per month).

Released 2020-04-05, updated 2020-10-15.

Version: 2004.201015

I'm not in love with that, but that's how I'd assume it'd work.

Post reply on HN