The only reason fixed-width integer types exist is more or less a hack/optimization for doing fast and space-efficient integral math. Since these are total non-issues for the problem domain where version numbers are involved, there's no reason not to use a bignum instead, if available.

Similar test: which is a more appropriate data type for ZIP codes, int or string?

Non US ZIPs regularily have strings in them (e.g. Dutch ZIP codes) so a string would be appropriate.

This is half right. String would be more appropriate than an integer type even if that weren't true. ZIP codes really don't have anything to do with the fundamental numerical operations that are defined for integer types.

plus zip codes can start with "0". Excel always screws this up

Obviously it's int, so you can do stuff like int zip_code = 01918 in C and then wonder why it doesn't even compile.

/s

When you say ZIP, do you mean USPS ZIP? USPS ZIP+4? Or non-US postal codes?

Or all of the above?

I ran into that about 10 years ago with a certain infrastructure as code framework.

I versioned my code as YYYYMMDD.patch then couldn’t get subsequent versions to deploy. After enough debugging I figured out it was due to my major version silently causing an integer overflow.

Maybe fixed now, but my recollection is that .msi installers for Windows were limited to 0-255 for major and minor. Which sucked as I was trying to transition software using the year number as major.