How about using the same strategy as planned OS releases - e.g. there will be a new rolling release of the QUIC spec at least once a year on March 21 that, as a minimum, greases the codepoints and salts. Officially, the new release could be identified with a label such as something like "v01-2022r01" with the actual on-wire version number generated as a hash of that label.
If necessary, each new release (and associated on-wire version number) could also come with a pre-determined sunset date after which it is not expected to be supported by deployed implementations. Having a calendar for QUIC updates may also help with planning for all interested parties. The label "v01" refers to the RFC of the base protocol, i.e. RFC 9000. If there is a real change to the base protocol, it can be given the label "v02" in a new RFC. Cheers ... /bill > Hi Martins, > > Wearing no hats. > > > On Sat, 22 Jan 2022, 02:05 Martin J. Dürst, <[email protected]> wrote: >> >> Hello everybody, >> >> The following concern just popped up in my mind: >> >> Some people (in particular the press,...) may take version numbers very >> seriously. Reading "QUIC version 2", my guess is that there might be >> articles saying things such as "Quic already is at version 2" or "Quic >> version 1 is outdated, use version 2", and so on. >> >> Everybody on this list (including me) of course understands that such >> stuff is completely wrong, and it's easy for people who want to figure >> out that it's wrong. Nevertheless, there are quite a few instances where >> version numbers have taken a life of their own. >> >> The purpose of this mail is that everybody consider the risk of the >> above "misunderstandings". If we are fine with that risk, then let's go >> with "version 2". If we have some doubts, it would be easy to change the >> version number to something else, such as 1.1, or 0.99, or A.bc, or >> whatever. >> > > Whatever moniker we chose, I think there will be some part of the > population that will be surprised and read something more into it than what > the specification is attempting to do or solve. Personally I think QUIC 1.1 > would be a very bad name though. > > I've lost count of the times I've seen a comment like "I've only just heard > about HTTP/2, and now there is an HTTP/3?". > > This spec will help exercise our version negotiation mechanism and help > prevent stagnation and ossification. In some sense we are trying to build > an evergreen transport, to borrow a w3c term [1]. Perhaps people should > become accustomed to a new version of QUIC being released on a regular > cycle, so that implementer and operators build out the processes needed to > stay compatible and up-to-date. > > Cheers > Lucas
