4 ms·

There 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 y

• DSMan195276 5y ago
  I'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.
  • Jenk 5y ago
    We agree. :) A "Version Number" is not just a "Number", as I said right at the start. Just to clarify, having an integral incrementing number as the whole version number strategy explicitly prohibits the use of major/minor/patch. Unless you intend on using 0s (instead of fullstops) as delimiters I suppose. Edit: as you demonstrate in your post. I'll stop posting now :)