[SERVER-58346] Calculate generic WireVersion enum constants Created: 07/Jul/21 Updated: 29/Oct/23 Resolved: 09/Aug/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Xuerui Fa | Assignee: | Xuerui Fa |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Repl 2021-08-09, Repl 2021-08-23 | ||||
| Participants: | |||||
| Description |
|
Today, the WireVersion enum is like this:
Remove all values starting with WIRE_VERSION_47. These values are used only by class WireSpec to determine if an incoming client is compatible with this server, and to fill out the min/maxWireVersion fields of the "hello" reply. Instead, calculate the latest, last rapid, and last major wire versions at runtime from the generated kNumberOfReleasesSince44 constants. For example, the latest wire version is RESUMABLE_INITIAL_SYNC + kNumberOfReleasesSince44. |
| Comments |
| Comment by Xuerui Fa [ 12/Jan/22 ] |
|
Sorry, I was being unclear! We are currently developing 5.3, so master is 5.3 and its wire version is 16. You're correct that 4.5 never received a wire version. The project that implemented this change, PM-2091, did not modify previous behavior, so we decided to maintain that in the new implementation. releases.yml is indeed the source of truth and is used to calculate multiversion::kSince_4_0. |
| Comment by Jeremy Mikola [ 12/Jan/22 ] |
|
xuerui.fa: I do have a follow-up question. You said:
Does that mean that 5.3 reports wire version 16? Or since 5.3 has been tagged, the master branch reports 16 and a 5.3 release would report 15? It looks like a 5.3 branch has yet to be created, so perhaps 5.3 and master are one and the same in this respect – in which case 5.3 is 16. I understand 5.0 is historically wire version 13 and that will not change. But if server versions 5.1 and later now calculate the latest wire version as REPLICA_SET_TRANSACTIONS + multiversion::kSince_4_0 (where REPLICA_SET_TRANSACTIONS is 7), it's still a bit unclear as to how multiversion::kSince_4_0 is calculated. For the math to work out such that 5.3 reports wire version 16, multiversion::kSince_4_0 would need to be 9. I think that works if we pretend that 4.5 never existed:
It sounds like that's the case. If it's not too much trouble, can you sanity check me on determining how the 4.5 release is actually ignored? I originally assumed that releases.h.tpl was generated from git tag information, it looks like the actual source of truth is a releases.yml file passed as a command-line argument. If so, I suppose 4.5 is just never mentioned in that file. Digging a bit further in the server repository, I did find src/mongo/util/version/releases.yml, so perhaps that's our new source of truth. It does omit 4.5 as I would have expected. |
| Comment by Xuerui Fa [ 12/Jan/22 ] |
|
jmikola Yes, I believe your three points are correct. Going forward, the wire version will be incremented by 1 for each release, including rapid releases for continuous delivery. So since we just released v5.3, the latest wire version is currently 16. I think wrt the previous wire versions, I believe everything from 4.5-4.9 was consider an internal release to test continuous delivery. I'm not sure why we don't have a wire version for 4.5, leading to 13 instead of 14 for 5.0, but going forward we will definitely increment once per tagged release version. Feel free to ping me if you have any other questions! |
| Comment by Jeremy Mikola [ 11/Jan/22 ] |
|
xuerui.fa: I've been tasked with investigating the downstream impact for drivers here. Drivers engineers have historically looked to wire_version.h for determining the exactly wire version for each server release. For added context, drivers use wire versions to detect support for various server features (e.g. wireversion-featurelist.rst). I noted that mongodb/mongo@efdac64 for Going forward, it seems as if driver engineers will need to manually calculate this for each release. We already keep a record in wireversion-featurelist.rst, so I expect that will just become our authoritative reference. That said, I do want to confirm a few things:
With regard to the last bullet: In the past, there were cases of larger wire version bumps between public releases. Using 4.4 (wire version 9) and 5.0 (wire version 13) as an example, it's not clear to me how that would have been calculated using this new system. There were four tagged minor versions between 4.4 and 5.0 (4.5, 4.7, 4.8, and 4.9), which would suggest wire version 14 for 5.0. I understand this new calculation only applies going forward (5.1+), so hopefully this isn't anything we'll need to worry about with the new quarterly/LTS release schedule. |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 09/Aug/21 ] |
|
Author: {'name': 'XueruiFa', 'email': 'xuerui.fa@mongodb.com', 'username': 'XueruiFa'}Message: |