chris 24158 (6/21/2016)
I'm confused. It appears you now advocate not upgrading if the SQL version is less than eight years old -- SQL2008R2? Forgive me, but I didn't read that in your initial post about how great SQL 2016 was.
You stated "it's also the most tested and evaluated" and I responded with a Microsft post about how the SQL 2016 instance can crash. You responded with a vague reply about version mismatch. Please correct me if I am wrong:
My point is SQL 2016 is in no way ready for production, and it is incredibly irresponsible to in any way insinuate that SQL 2016 should be deployed to production.
Your point is wrong, and it's incorrect to state SQL 2016 isn't ready for production. The issue you refer to is a version upgrade in the C++ DLLs that is needed. This is a timing mismatch. Some systems out there are on older versions of the C++ DLL, which is from 2013 runtime. This needs to be updated. This isn't a SQL Server item, but potentially an issue with the rest of your system.
Could SQL Setup update this? Sure, but that's not the mandate of the SQL Server team. This is a system outside of SQL Server. This has happened in the past with Windows or VS not including an update in their system as they released first, or later, or something else.
If you think this is a big deal, or it's poor writing of the SQL Server code, I'm not sure how to convince you. This is a dependency on other parts of the Windows host. As I mentioned, I haven't had to apply this, some have, some haven't. This isn't a stability issue for SQL unless you refuse to apply the patch. In that case, don't upgrade.
I advocate doing what's best for your business. SQL Server 2016 is the best release to date, in my opinion. That doesn't mean I'm upgrading SQLServerCentral databases. It's not business effective for us and we don't use the newer features. However, if you can, or you benefit from the change, or need to be supported for your business, it's worth looking at.