Why does the SQL Server build number sequence not correlate with the release date sequence? I'm looking at the Microsoft SQL Server 2016 Builds (see that section heading). The list of builds is given in build number order. That is, at the top of the list is the &quot;highest&quot; build number, and each subsequent row has lower build number than the one before.
However the release dates don't correlate with this. So here are 5 rows, for example:

Build 13.0.5081.1 - released 14/08/2018
Build 13.0.5101.9 - released 9/07/2019
Build 13.0.5102.14 - released 11/02/2020
Build 13.0.5149.0 - released 30/05/2018
Build 13.0.5153.0 - released 17/07/2018

The general sequence for builds around this time comes from 2018 - and then we have those 2 odd rows, from 2019 and 2020 and then back to the general sequence from 2018.
If a cumulative update is supposed to contain all prior cumulative updates, then how could that last build (in the 5 above) have contained the updates from the two builds from 2019 and 2020? (Oops - only just noticed the first line is from Aug, which is after the 4th and 5th lines too!)
If I had installed the 4th and 5th builds at the time of their releases (in May 2018 then July 2018), and then that 1st build gets released in Aug 2018 - would I automatically have had those changes incorporated already? If so, what was the point of issuing an older build number?
Another example
Here is another example that just makes no sense to me.

First, the RTM is dated June 2016. Then the first cumulative update - CU1 - is dated July 2017, which is 10 months after CU2 was released in Sep 2016. Huh?
And read the text at the bottom - &quot;After certain Cumulative Updates, Microsoft released a Service Pack for SQL Server, which contains the entire previous fixes, Cumulative Updates, and hotfixes&quot;. Huh again? Note SP1 was released November 2016 and a full 7 of the 9 cumulative updates - correction, &quot;previous ... Cumulative Updates&quot;, according to the caption - were released in 2017 after the Service Pack.
Table is from MSSQLTips.
Build 13.0.5101.9 - released 9/07/2019 is
https://support.microsoft.com/en-us/help/4505220/kb4505220-security-update-for-sql-server-2016-sp2-gdr-july-9-2019
Build 13.0.5102.14 - released 11/02/2020 is
https://support.microsoft.com/en-us/help/4532097/kb4532097-description-of-the-security-update-for-sql-server-2016-sp2-g
These are General Distribution Release (GDR) builds, intended to be installed by all customers running the affected Service Pack level.
Basically, those are critical patches for SQL 2016 SP2 which don't require installing any of the Cumulative Updates.
The relevant fixes would also have been included in the next CU, and probably available as a hotfix for the current CU.
As for the build numbers, GDR is a seperate branch from CU.  It's tricky to apply a single build number system to a branched codebase, but the strategy appears to be that the GDR build numbers are placed between the common root build number (SP2) and the first CU (SP2 CU1).

if I upgrade my system to 13.0.5149.0,

That's CU1, and once you are on the &quot;CU Train&quot; you must apply subsequent CUs to get fixes.  That's why the KB's say

To apply this update, you must have SQL Server 2016 SP2 or any SQL
Server 2016 SP2 GDR release through this SQL Server 2016 SP2 GDR
installed.