On Fri, 11 Apr 2025 at 21:39, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> While checking the code in older branches, I noticed that the returned
> protocol version is always the latest version supported by the server.
> However, as we discussed, in master, the server may return the version
> requested by the client. The change was introduced in commit 516b87502dc.
> So, probably we'll need to update the documentation differently for
> master and the older branches.
No need for different docs. Given that older branches only support 3.0
protocol, there's no way for a client to request a version earlier
than the "latest version supported by the server".
> The patch adds a new explanation about when the NegotiateProtocolVersion
> message is sent. But a similar explanation already exists in protocol.sgml:
Side-comment: I think our protocol docs are pretty annoyingly spread
across two pages.
> Given that, I'm now wondering if the new description in the patch
> might be redundant.
>
>
> Also, your original concern was that the phrase "Newest minor protocol version"
> is inaccurate since the field contains both major and minor version numbers
> (e.g., 3.2). However, based on other usage in protocol.sgml and source
> comments in related code, "minor version" seems to refer to the full version
> like 3.2, i.e., not just the minor part, so we might not need to reword it
> after all.
I quite like the new wording from Dave so +1 from me. I also think for
protocol docs it's especially important to be very precise and leave
very little room for interpretation.
One thing that we should probably clarify though (which was somewhat
clarified in the previous wording) is that we only send this message
if the client requested a major version that the major version that
the server supports. i.e. we will never send a
NegotiateProtocolVersion message to 3.2 if the client requested 4.0.
