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

21–30 of 102 posts

Re: CalVer: Calendar Versioning

#21

Post by RKearney »

> YY - Short year - 6, 16, 106

> [...]

> Note that traditional, incremented version numbers are 0-based, whereas date segments are 1-based, and the short and zero-padded years are relative to the year 2000.

Y3K here we come!

Re: CalVer: Calendar Versioning

#22

Post by vegardx »

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…

That can be said about any versioning scheme. The idea that making things inconvenient suddenly makes people do the right thing is pretty naive, if you ask me.

Semantic versioning lets the user decide.

Re: CalVer: Calendar Versioning

#23

Post by rtpg »

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…

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”

Re: CalVer: Calendar Versioning

#26

Post by timeattack »

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 along with specific information for developer for bug reporting. Also, it allows intraday releases.

Re: CalVer: Calendar Versioning

#27

Post by SamWhited »

For some projects I like the idea of calendar based versioning, sadly I mostly write Go and they've decided that anything but semver isn't allowed if you want to use the new packaging standard, Go Modules :(

Re: CalVer: Calendar Versioning

#29

Post by NaNtales »

One use case for this that comes to mind is for patching multiple major versions with a particular fix.

For example, you might release a hotfix patch today that fixes a bug in all major versions of your software. Using calendar versioning as a patch number would give something like

- 3.4.20200106

- 2.1.20200106

- 1.5.20200106

making it very easy to tell whether a particular version includes todays fix or not.

Post reply on HN