5 ms·

There's a RFC 1912 from 1996 explaining this versioning strategy which was already in common use for DNS SOA record serial numbers. https://tools.ietf.org/html

by VLM 7y ago

There's a RFC 1912 from 1996 explaining this versioning strategy which was already in common use for DNS SOA record serial numbers. https://tools.ietf.org/html/rfc1912 https://tools.ietf.org/html/rfc1912 I'm sure this strategy vastly predates 1996 in other computer applications. Julian dates have a similar purpose, and have been used in the US Military Logistics system for a very long time, but I can't figure out how far back. Also some food products, beer especially, with "secret" expiration or manufacture dates, according to civilians anyway, are often strangely formatted Julian dates.

ctvo 7y ago
Agreed it's not a new idea, but I'm not discounting adding a catchy name to it and a well-made website with a clear specification. That will get people using it in some open-source communities (Node / JavaScript specifically). The problem with SemVer is that library owners are not strict with its intended usage (backwards incompatible changes in patch!) or don't fully understand it. Perhaps having a much more simple versioning strategy will help in some use cases.
- strbean 7y ago
  > The problem with SemVer is that library owners are not strict with its intended usage The worst case I saw was when someone was just appending 9's to the version number every release (0.99999 -> 0.999999). I think this was a joke about asymptotically approaching version 1.0. The effect was that some error message when solving dependencies came out as "X wants version 0.99999999999, but Y wants version 0.99999999999". Very annoying!
- NetOpWibby 7y ago
  > The problem with SemVer is that library owners are not strict with its intended usage What's the point of doing it if you're not gonna do it right? Thanks for the kind words!
- VLM 7y ago
  Sorry for the super late followup, but yeah my point was a pretty good selling point might be its been an operationally useful, apparently optimized, and successful solution for many decades in the fields of X, Y, and Z, and the more examples of success, the better.
NetOpWibby 7y ago
I was eight years old in '96. I wish this versioning strategy caught on then. Maybe I should add a "prior art" section on the site, thanks for the link!

by VLM 7y ago

ctvo 7y ago

Agreed it's not a new idea, but I'm not discounting adding a catchy name to it and a well-made website with a clear specification. That will get people using it in some open-source communities (Node / JavaScript specifically). The problem with SemVer is that library owners are not strict with its intended usage (backwards incompatible changes in patch!) or don't fully understand it. Perhaps having a much more simple versioning strategy will help in some use cases.

strbean 7y ago
> The problem with SemVer is that library owners are not strict with its intended usage The worst case I saw was when someone was just appending 9's to the version number every release (0.99999 -> 0.999999). I think this was a joke about asymptotically approaching version 1.0. The effect was that some error message when solving dependencies came out as "X wants version 0.99999999999, but Y wants version 0.99999999999". Very annoying!
NetOpWibby 7y ago
> The problem with SemVer is that library owners are not strict with its intended usage What's the point of doing it if you're not gonna do it right? Thanks for the kind words!
VLM 7y ago
Sorry for the super late followup, but yeah my point was a pretty good selling point might be its been an operationally useful, apparently optimized, and successful solution for many decades in the fields of X, Y, and Z, and the more examples of success, the better.

NetOpWibby 7y ago

I was eight years old in '96. I wish this versioning strategy caught on then. Maybe I should add a "prior art" section on the site, thanks for the link!