8 ms·
> Version numbers They still aren't compatible with number types. They are groupings of numbers at best. 2.9 is an earlier (not less than) version than 2.10.
by Jenk 5y ago
> Version numbers
They still aren't compatible with number types. They are groupings of numbers at best.
2.9 is an earlier (not less than) version than 2.10.
3.1.6 isn't a (strict) numerical format.
5.4.11-beta1 has non-numerics.
- tuwtuwtuwtuw 5y agoIf you define your version numbers to be numbers, then your version numbers will be numbers. I really don't get the confusion over this.
- Jenk 5y agoThe assumptions/traits/expectations that come with numbers (and most importantly, that are embedded into the number _types_) may not be consistent with _version number_ types.
- tuwtuwtuwtuw 5y ago
- Jenk 5y agoI think you need to read the thread again. The point (there is just one) I've made in both replies has been very clear and direct.
- tuwtuwtuwtuw 5y ago
- Jenk 5y ago
- Spivak 5y agoI mean if your standard for “numbers” is “can be mapped 1-1 to integers” then everything is a number. The operations you actually do to numbers have to have meaning in the space you’re defining. Does “1.2.0” + “2.3.0” make sense in your world? And if you’re like what about ordering and comparisons, then sure, you have a partially ordered set.
- tuwtuwtuwtuw 5y agoI don't get what you're trying to add. If Microsoft defined their version numbers as an integer then it's an integer value. They didn't define it as say "1.2.0" so not sure what that has to do with anything.
- Robin_Message 5y agoDates can be very meaningfully and sensibly converted to/from a numeric representation, yet the addition of two dates doesn't make sense, so I don't think not bring able to add versions holds. And not everything can be mapped 1-1 with the integers; reals for example, and therefore arbitrary strings. (Of course, that's only theoretically; with a limited string length you can obviously manage) You're right that the ordering is the key feature of a version representation; munging it into an integer gives you that for free but risks getting to overflow quite easily (as in this case). I guess the conclusion is, use a language like Rust or Ruby when you can define ordering easily on structured data.
- tomjakubowski 5y agosomebody better tell Cantor...
- rat9988 5y ago> 2.9 is an earlier (not less than) version than 2.10. Not necessarily. Some projects go from 2.9 to 3. I'm not sure what you are trying to prove.
- Jenk 5y ago> They still aren't compatible with number types.
- rat9988 5y agoWhy?
- solarengineer 5y agoFor software version numbering, I consider 2.9 to have been released "earlier than" 3 (and not lesser than 3).
- detaro 5y agoThe reference was > Version numbers the way they’re used here And none of that applies to them. Yes, there are versioning schemes that work differently, irrelevant to the example here.
- marcellus23 5y agoDid you read the link that we’re all discussing here? The versioning scheme they use is not any of those formats.
- DSMan195276 5y agoIgnoring the tags (which not everything uses) it's possible to express all of those as a single increasing number by simply putting enough zeros in, which does make them representable as simple numbers, so I think you're kinda splitting hairs. Most version number representations/libraries will likely do something similar to read it anyway even if you keep it a string - split it into separate individual numbers and compare major/minor/patch/etc separately, and by virtue of fitting the individual parts into separate integers you're giving them all a maximum value, which is what the zeros would do. The problem is they shoved the individual parts into a single 32-bit integer, which just isn't enough space so they had to compromise and make some of the numbers have extremely small ranges.
- Jenk 5y agoThere are exceptions to that rule, however - Maintenance releases. Node, Typescript, Java, .NET, and I'm sure many more obvious instances I need not list. If you "just" increment you leave no room for showing patching in your versioning strategy.
- DSMan195276 5y agoI'm not entirely sure what you're getting at? That's the point of the `feature` and `patch` version numbers. If you want you can put a 4th or 5th number in there as well to fit whatever uses you have. Perhaps you're missing what I meant by 'increasing' - it's just a 1:1 conversion of the version number to a single integer, it's not like you're assigning every version a new number. 3.9.3 would become something like 3009003, and 3.10.1 would become 3010001. If you compare those representations then 3010001 always compares higher, and there's also nothing preventing you from releasing 3.9.3 after 3.10.1. My point was that doing a format like the above (major, 3 digit minor, 3 digit patch) is not fundamentally different from storing each individual number as it's own integer, which most version libraries I've seen do at some point. The problem is just that the range of each number is restricted significantly by requiring 3 digits rather than if you used individual 32-bit or 16-bit integers for each one.
- 5y ago
- nottorp 5y agoGoogle is forcing all Android applications to have both a version name, which is an arbitrary string that's only used for displaying to the user, and a version code, which is a plain integer and is what is used to decide which is the latest version that will be installed. That should fix a lot of version number problems (prolly not all) and i've been stealing the idea for my own versioning lately.