In TLS, the client announces its maximum supported version. Then the server responds with the protocol version that will actually be used for the connection.
So for instance, if a server knows TLS 1.0 and 1.1, and the client announces "I support up to TLS 1.2", the server, without knowing what TLS 1.2 may be, can still respond: "fine, we'll use 1.1".
Theoretically, if a client says "I support up to TLS 1.38" (which will be encoded in the
ClientHello as two bytes of value 0x03 0x27), a server who supports up to TLS 1.2 will not have any clue of what TLS versions 1.3, 1.4... to 1.38 are (and, indeed, such versions don't exist yet, the maximum defined being TLS 1.2 right now); however, that server can still say: "1.38 is higher/later than 1.2, so the client should know about TLS 1.2" and proceed with stating: "we will use 1.2".
In practice, some servers are poorly written, and when a client says "TLS 1.3" they drop the connection. This is a server bug; but a widespread one. That bug is often designated by the expression "version intolerance". Some of these buggy servers accept some kinds of unknown versions, but not all. E.g. some servers would tolerate any "1.x" version for any x in the 0 to 254 range, but would reject a version "2.y".
Because of version intolerance, clients (Web browser) must already include contingency code which tries several times. E.g. it first try to connect with "1.2" in the
ClientHello, but if the connection fails, the client tries again with "1.0" as maximum supported version. This is tiresome and kludgy. A server that does not tolerate TLS version 1.3 is a server that will be troublesome when TLS 1.3 is specified and browsers begin to use it.