October 2, 2017 at 9:15 pm
Comments posted to this topic are about the item No More Service Packs
October 3, 2017 at 6:02 am
It will certainly simply patching. I hope vendors take testing CUs more seriously than they do Service Packs now.
October 3, 2017 at 7:35 am
I trust Microsoft, particularly the SQL Server team, to do this right and to do it for the right reasons. It's probably the best engineered software product in the world.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 3, 2017 at 8:33 am
I think this decision further demonstrates that Microsoft is out of touch with their customer's needs. Releasing a major version of their software in a year and a half, and doing monthly updates of it drives people like me nuts because it shows that the product is unstable. Businesses want things to work, and work right the first time, not eventually. If I propose this schedule to the rest of the folks here in my IT department they would laugh, there is no-one available to do monthly testing of these updates, it takes more of my time to manage all these updates, and it has to make the product more difficult long term for Microsoft to support.
October 3, 2017 at 8:41 am
Chris Harshman - Tuesday, October 3, 2017 8:33 AMI think this decision further demonstrates that Microsoft is out of touch with their customer's needs. Releasing a major version of their software in a year and a half, and doing monthly updates of it drives people like me nuts because it shows that the product is unstable. Businesses want things to work, and work right the first time, not eventually. If I propose this schedule to the rest of the folks here in my IT department they would laugh, there is no-one available to do monthly testing of these updates, it takes more of my time to manage all these updates, and it has to make the product more difficult long term for Microsoft to support.
It appears that Microsoft is attempting to turn SQL Server into a Windows patch schedule methodology.
We will never be able to keep up with monthly or even every other month CU releases. Not to mention the fact that if it is a purchased application we have to wait for the vendor to certify it or risk losing support if an issue arises.
October 3, 2017 at 8:55 am
Summer90 - Tuesday, October 3, 2017 8:41 AMIt appears that Microsoft is attempting to turn SQL Server into a Windows patch schedule methodology.
We will never be able to keep up with monthly or even every other month CU releases. Not to mention the fact that if it is a purchased application we have to wait for the vendor to certify it or risk losing support if an issue arises.
And I guarantee that in many places Windows patches DO NOT get properly tested! People do silly things like applying the updates to a test server for a week and if no-one complains then it must be all good. I value my databases and the data within them too much to let that happen.
October 3, 2017 at 9:47 am
Summer90 - Tuesday, October 3, 2017 6:02 AMIt will certainly simply patching. I hope vendors take testing CUs more seriously than they do Service Packs now.
They take SP testing seriously. There is a lot of testing. There's even more to test. I really think that SPs are out of band, a separate process that means extra steps and potentially a different testing stream. I used to prefer SPs, but I think at today's pace and the way that software is moving, a constant patching process makes sense.
October 3, 2017 at 10:40 am
Another thing to keep in mind for SQL Server... most of the new features have been in place in Azure SQL Database for quite some time before making it to the on-premises versions. Meaning that it's been tested for a while before making it to those versions - which should mean fewer bugs in the on-premises versions.
@summer90: You don't have to do monthly patches - just use whatever cycle that you're comfy with. If you find an issue that is fixed in a CU already, you can always do a special patch. You make a valid point about 3rd party software needing the vendors stamp of approval.
@steve-2: I think that Summer90 was talking about 3rd party vendors, not Microsoft,
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
October 3, 2017 at 10:45 am
I guess this an effort on the part of Microsoft product teams to better synchronize shared code bases, builds, and testing between SQL Server 2016/2017 and Azure SQL Database, which would be less branching and duplication of effort on their part going forward.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 4, 2017 at 5:12 am
Eric M Russell - Tuesday, October 3, 2017 10:45 AMI guess this an effort on the part of Microsoft product teams to better synchronize shared code bases, builds, and testing between SQL Server 2016/2017 and Azure SQL Database, which would be less branching and duplication of effort on their part going forward.
Having recently reduced our main product from four branches to three I can see many advantages in this!
We are currently on SQL Server 2012 which is due SP4 any day now (although it seems a variable feast). I am quite wary of SPs after having had a major issue with an OS related one in the noughties!
October 4, 2017 at 6:58 am
Eric M Russell - Tuesday, October 3, 2017 10:45 AMI guess this an effort on the part of Microsoft product teams to better synchronize shared code bases, builds, and testing between SQL Server 2016/2017 and Azure SQL Database, which would be less branching and duplication of effort on their part going forward.
I'd say they are producing just as many code branches as before, since they seem to be releasing new major versions more frequently. If they create one major version with a service pack in 3 years, or 2 major versions in that same 3 years, there would seem to be the same number of branches.
October 4, 2017 at 7:52 am
Chris Harshman - Wednesday, October 4, 2017 6:58 AMI'd say they are producing just as many code branches as before, since they seem to be releasing new major versions more frequently. If they create one major version with a service pack in 3 years, or 2 major versions in that same 3 years, there would seem to be the same number of branches.
Interesting. With 2016, there is an RTM branch and an SP1 branch, plus a potential GDR branch for each. Also, the 2017 branch. So 5.
Looking forward to 2018, there will be a 2017 branch (GDR), 2017 branch (CU) and 2018 branch. Three.
Now, if we look back , right now there are certainly 2012 and 2014 branches, so potentially 4 each, that's 9 for now. If we go 5 years down the road, there will be
2017 - 2
2018 - 2
2019 - 2
2020 - 2
2021 - 2
2022 - 2
2023 - 1 (in dev)
That's 13, assuming that 2023 releases and gets a CU before 2017 falls out of mainstream. So, yes, more branches, hopefully streamed closer in lineage to where we've been in the past.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply