On Mon, Dec 8, 2025 at 1:43 PM Jelte Fennema-Nio <[email protected]> wrote: > 1. We still have fairly limited experience with protocol options, so > afaik not everyone agrees what we should use a version bump for vs a > protocol extension.
I think it'd be helpful for proposals to describe why a minor version bump was chosen over a protocol extension parameter (or vice versa), so that we can begin to develop some consensus. To me, the conversation on the wire for this feature seems perfect for an extension parameter: "Hello server, do you support this optional thing in this one message type? If not, let me know." Especially since the optional thing is itself an extensible bitmap! With the minor-version strategy, if we added new bits in 3.6, clients who just wanted those new bits would then have to implement support for every feature in versions 3.4, 3.5, and 3.6 just to improve that one use case, and that incentive mismatch leads to more ossification IMO. = Soapbox Follows = I've talked about it face-to-face with people, but to go on the public record: I don't think this is a wise use of a minor version upgrade strategy. I prefer protocol architectures that introduce separate extensions first, then periodically bundle the critical and highly-used extensions into a new minor version once they're sure that _everyone_ should support those things. I know that 3.2 didn't do that. My view of 3.2 is that it was a big compromise to get some things unstuck, so overall I'm glad we have it -- but now that we have it, I'd rather that 3.next be more intentional. Plus I think it's unwise to introduce a 3.3 before we're confident that 3.2 can be widely deployed, and I'm trying to put effort into the latter for 19, so that I'm not just sitting here gatekeeping. IETF has a bunch of related case studies [1,2,3] that might be useful reading, even if we decide that their experience differs heavily from ours. --Jacob [1] https://www.rfc-editor.org/rfc/rfc5218 [2] https://www.rfc-editor.org/rfc/rfc8170 [3] https://www.rfc-editor.org/rfc/rfc9170
