I thought this was a new team calendar that was version controlled when I first read the headline. And now I want that.
CalVer: Calendar Versioning
31–40 of 102 posts
Re: CalVer: Calendar Versioning
#32> 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!
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.
Re: CalVer: Calendar Versioning
#33For 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 :(
Funny thing is, the previous tools for Go and tools in other languages tell you SemVer but you have enough control that you can use CalVer if you like.
Re: CalVer: Calendar Versioning
#34You should probably consider changing the name. https://translate.google.com/?hl=fr#fr/en/calvaire
I thought the same!
Re: CalVer: Calendar Versioning
#35I'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…
You can also just use "git describe" to get more or less the exact same information, which is useful for development releases that are untagged when using versioning schemes like semantic versioning.
Re: CalVer: Calendar Versioning
#36I'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…
It helps to have the versioning ordered correctly, so I'd zero-pad the ${count} variable, like so:
printf "%s.%03d_%s\n" $date $count $commitRe: CalVer: Calendar Versioning
#37> 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!
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.
This specification defines `YY` and `0Y` as switching to 3 digits for 21xx (i.e. it outputs it as 1xx).
Re: CalVer: Calendar Versioning
#38> 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!
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.
Re: CalVer: Calendar Versioning
#39You 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.
That's for web browsers though, which get to be early movers. In terms of the standards organisations the IETF's Best Common Practice update to deprecate TLS 1.0 (and TLS 1.1 which wasn't widely deployed before TLS 1.2 anyway) is still working its way through the bureaucracy. Currently:
https://tools.ietf.org/html/draft-ietf-tls-oldversions-depre...
Although I liked its original name (oldversions-die-die-die) obviously that's one of many things that couldn't survive in a publicly endorsed document.
Re: CalVer: Calendar Versioning
#40I thought this was a new team calendar that was version controlled when I first read the headline. And now I want that.
I had exactly the same thought, it's kind of an interesting idea. I'm not 100% sure what the usefulness is though.