4 ms·
The only reason I can think of is that storing a version as a number would allow you to check if your version is incompatible with another server or feature / e
by zitterbewegung 5y ago
The only reason I can think of is that storing a version as a number would allow you to check if your version is incompatible with another server or feature / extension. By using less than or greater than.
- frays 5y agoIf they were stored as characters you could still do a string comparison using greater than and less than signs and logic. "202201010001" > "202112122359" evaluates to True in Python, SQL and many other languages.
- oefnak 5y agoBut "1000"<"999" in Python.
- thomasfedb 5y agoBut the format and length for these numerical strings is fixed.
- jpambrun 5y agoThis is going to be a problem in about 8,000 years tho.
- laumars 5y agoString comparison works as long as you order your date time by significance and zero pad all values, which they were doing with their date stamp anyway. Plus if they weren’t then even numerical comparisons would fail eg 1012021 (Oct/1/2021) < 5102020 (May/10/2020) so you argument is moot.
- 6c696e7578 5y agoWouldn't it be done more like this though? "%04d%02d%02d" % (999,1,1)
- ilikehurdles 5y agoNot necessarily. 2.2 is greater than 2.12 but v2.2 is actually an early predecessors to v2.12
- zmmmmm 5y agothat is exactly why you would create a transformation to something like a big fat integer with each segment of the version number isolated to separate parts of the bit mask so you can compare it as an integer.
- mmis1000 5y agoThat would work if padding is always forced (like date). And in this case, it actually is. 2.02 is smaller than 2.12
- pfooti 5y agoBest hope you don't end up releasing 2.100 then
- mmis1000 5y agoIt can also ends up as 2.99.01. Jokes aside, there is another bug caused by some poor programmer hard-coded the length of version field recently. https://news.ycombinator.com/item?id=29702128 https://news.ycombinator.com/item?id=29702128