On Tue, Aug 20, 2024 at 1:02 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> So basically my proposal amounted to making every update a "major version update" and changing the behavior
surroundingNegotiateProtocolVersion 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'tbeen materially implemented. Otherwise, at some point a client that knows both v3 and v4 will exist and its
connectionwill be rejected instead of downgraded by a v3-only server even though such a downgrade would be possible. I
suspectwe'd go ahead and change the rule then - so why not just do so now, while getting rid of the idea that minor
versionsare a thing.
>
> I suppose we could leave minor versions for patch releases of the main server version - which still leaves the first
newfeature 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
