Does that mean that we can have all that number of versions for a single class? I assume not. I'm seeing it to be much shorter primitive.
What is a serialVersionUID and why should I use it? doesn't state why the guy implemented this mecanism has chosen it to be a long value.
The type of serialVersionUID should be long because that is how it was specified. See http://docs.oracle.com/javase/8/docs/platform/serialization/spec/class.html (specifically section 4.6)
The reason that the UID is 64 bits is that the risk of accidental UID collision would be too high if (say) 32 bit values were used.
The default serial version UID generation scheme creates a hash based on classes methods and fields. There is a small, but non-zero, that two different classes will have the same default UID. If this happens, then the deserializer may not notice that serialized form of the object is incompatible with the slass we are trying to deserialize to. Bad things would then happen.
If 32 bit UIDs were used, the chance that two incompatible classes had the same UID would be one in 232. That is about one chance in 4 billion. That is too large a chance. With 64 bit UID values, the change is one in 264. That is about one chance in 16 quadrillion. That was deemed (by the designers) to be an acceptably small probability.
