Hey, Responding to the theme of this thread, as an individual.
I think it's a laudable goal to have scheduled releases and up-front support cycles. However, I fear what that requires is switching the group from a QUIC standards development and maintenance transport WG into a software and hardware delivery and operations group. Yes, if there are problems found in QUIC protocol versions or extensions, we should seek to fix them. However, I think it is a major challenge to attempt coordination across the diverse set of implementations and platforms where QUIC already runs. It also seems the antithesis of our goal in building an ossification-resistant protocol that encourages evolution and experimentation. Instead, as an individual, I would rather the WG continue to build robust versioning capabilities that allow the community to drive their own evolution. I trust the WG will, if required, make judgement calls on the right time and circumstances to deprecate IETF versions of QUIC. I would not be optimistic that we can drive deployments to change their supported versions just because we said so. Cheers, Lucas
