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 "highest" 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?
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 – "After certain Cumulative Updates, Microsoft released a Service Pack for SQL Server, which contains the entire previous fixes, Cumulative Updates, and hotfixes". Huh again? Note SP1 was released November 2016 and a full 7 of the 9 cumulative updates – correction, "previous … Cumulative Updates", according to the caption – were released in 2017 after the Service Pack.
Table is from MSSQLTips.