Back on September 21/22, Microsoft released its most recent cumulative updates for SQL Server 2008.  For RTM, this was Cumulative Update #7 (10.00.1818), and for SP1, this was Cumulative Update #4 (10.00.2734).

However, if you have requested the SP1 CU #4 hotfix download since November 4th, the download page has some new files up there, with "_Updated_Ref_KB_976761" in the name:

When you download these CU4 files, you will end up with a build number (10.00.2740) that is not documented in either of the above KBs, and the referenced KB (967671 – currently yielding Bing's version of a 404) has not been published at the time of this writing.  As Chris pointed out, KB 976761 appears to have been published today.  Though, a separate download page has been available all along, in addition to being able to download the new files from the original CU #4 download page.

Notice that the original KB for CU #4 (973602) still says that the version is 10.00.2734:

But then when you download the file with the KB #976761 designation, you get this:

And as expected, when you apply the update to your SQL Server instance, you get @@VERSION = 10.0.2740.0.

My question is: what kind of fixes were so important to quietly sneak these updates onto the CU #4 download page mid-stream?  My feeling is these should be separate.  The next CU should be coming out within the next several weeks, if they are going to stick to the same ~60 day schedule.  So I am curious what drives the priority to push the files to users before they push documentation explaining what the new files are.

I am sure this is just another case of the binary updates preceding the KB updates and other notifications (e.g. from the Release Services blog).  Personally, I think that the documentation updates and announcements should come out *before* they post the files; that would cause far less confusion.  What makes this scenario difficult is that the download page does not give users enough information about what these files are.  So if the 2740 build includes fixes that I don't know how to test, how do I know whether or not that should be one of the files I download?  What if I have tested CU #4 (10.00.2734) in my labs, and I tell the servicing team to apply CU #4 to production, and 10.00.2740 is the update they download?  This can be quite problematic, I'm sure you'll agree.

This is a relatively isolated situation.  But in general, I think the download pages need a lot more supporting documentation.  I know the purpose was for self-service, and it is kind of a contradiction that we want more control over what fixes we get without having PSS hold our hands, yet we still want more guidance from PSS.  But in my case, I still don't know what a "SQL_Server_2008_SP1_Cumlative_Update_4_RRB2ClickOn" file is, and whether or not I should download it and apply it to my servers.  With such a long file name allowed, why make the important part so cryptic?  (Naming of the file is obviously a choice made by a human; system-generated code would have spelled "Cumulative" correctly.)  Users have had similar questions about files on the download page, such as SNAC and SharePoint… while their naming is a little more intuitive to those of us who have been applying updates to our environments for a while, this isn't true for everyone.

A user on Connect ("ManServ") noticed this yesterday, and filed an item on Connect (#508983).  Hopefully I will have commented there by the time you get to it.  I realize that if the situation were reversed, we would just be bitching about the opposite thing: "You're talking about build 2740; why can't I download it already!?"  While both are equally annoying for PSS, I prefer the latter in terms of end users.  At least in that case, they are not downloading the files before there is any documentation around them; maybe they could focus on reading that documentation while waiting for the files to be pushed to the download servers.

I really wish I had noticed this at PASS, instead of right after getting home.  I actually had a conversation with Bob Ward during the conference, where he asked me how they can make this servicing model better.  The only constructive criticism I could come up with on the spot was that, when they are supporting two branches, and a fix makes it into one CU and not the other, document which fixes are only in one branch, and why.  This should be a companion KB article that is linked, in the case of SQL Server 2008, to both the RTM and the SP1 KB articles for the Cumulative Updates released at that time.  The way I currently figure this out is to build a table of both sets of fixes, and then figure out where the rows are not equal (you've seen me do this before, here and here).  It would be great if I could get that information from the source, however if I were to rank this, it would appear below the problem above, where files make it to end users' systems before there is even a document describing what those files are and what they fix.