On Tue, Aug 20, 2024 at 1:02 PM David G. Johnston <david.g.johns...@gmail.com> wrote: > So basically my proposal amounted to making every update a "major version > update" and changing the behavior surrounding NegotiateProtocolVersion so it > applies to major version differences. I'll stand by that change in > definition. The current one doesn't seem all that useful anyway, and as we > only have a single version, definitely hasn't been materially implemented. > Otherwise, at some point a client that knows both v3 and v4 will exist and > its connection will be rejected instead of downgraded by a v3-only server > even though such a downgrade would be possible. I suspect we'd go ahead and > change the rule then - so why not just do so now, while getting rid of the > idea that minor versions are a thing. > > I suppose we could leave minor versions for patch releases of the main server > version - which still leaves the first new feature of a release incrementing > the major version. That would be incidental to changing how we handle major > versions.
I don't see how this makes life any better for anyone. At some point in the future we may decide to make a protocol change that is big and breaks a lot of stuff, but the current goals are all to make minor changes that break as little stuff as possible. I think it's appropriate to call the latter a "minor" change and the former a "major" change. If we adopted this proposal, then we could end up in a situation where versions 3 through 17 are all mostly compatible and then version 18 is something totally different. It sounds much better to me to have versions 3.0 through 3.14 and then eventually 4.0. This is also what the person who designed the current protocol version numbering scheme seems to have had in mind, even if the implementation to make it a reality has been a bit lacking. -- Robert Haas EDB: http://www.enterprisedb.com
