Update: Mike Dietrich’s post on this and the linked MOS note confirm the new release schedule. I’ve included some updates in red related to what we know now, which we didn’t when the post was written. 🙂
Nearly a month ago I read Scott Wesley’s post on the new database patching cycle. That pointed to a post by Franck Pachot, which put a bit more meat on the bones. Recently we got the release of SQL Developer 17.2 and a link back to Jeff Smith’s post about their new release naming, which I had somehow missed. I just thought I would post some thoughts on this subject. This is based on that one publicly displayed slide (now confirmed). I have no insider information on this, so the contents of this post could be complete rubbish. It’s just speculation! 🙂
I really don’t have much of an opinion on the release cycles and versioning/naming of client tools. It’s nice to get regular releases with new bells and whistles, but for the most part you can choose to upgrade whenever you want and a downgrade is pretty simple if things go wrong. Case in point being SQL Developer and SQLcl, which are just “unzip and go”. Easy install. Easy backout.
The server side is a much bigger issue to me as this is where I can see the major pros and cons.
From the slides posted online, we are looking at something like this.
- Annual Release : It’s not clear if this is a “release” as we currently know it, but more frequent, or if this is the new major version each year. The slide mentions long term support for a “terminal release”. This implies it is not the major version, but Franck links to a bug that says fixed in 18.1, which suggests it is a major version. I guess we won’t know until the final announcement happens. 🙂 Update: It’s the major version according to the MOS note.
- Release Updates (RU) : Quarterly releases, kind-of like proactive bundle patches.
- Release Update Revisions (RUR) : Quarterly releases, looking something like critical patch updates (CPUs).
Update for Clarification : I am not too concerned about the lack of clarity about the process at the moment (now clarified by MOS note). It’s one slide in a presentation that no doubt had a safe harbour slide. 🙂 The things mentioned below are not so much concerned with the specifics of the process, more the resulting increase in the rate of change. There is often a discrepancy between the rate of change I would like personally as a content provider, and what a company using the products can reasonably keep on top of.
The pros listed below tend to be more focused on what I want, and the cons tend to be more focused on business practicalities as I see them. 🙂
- Quicker release of features : It can be a bit annoying to wait 4 years for a new feature. It’s also a bit annoying when you get a half-finished feature, knowing you will have to wait 4 years to get the final vision. As a content producer I like the idea of a quicker release of features!
- Predictable release cycles : It’s been a little odd in recent years. There have been long gaps between releases, then some patchsets have included really big changes. Some of those patchsets have included a load of new stuff that is undocumented. It will be nice to have a more predictable flow of features. Once again, as a content producer I like this.
- Upgrade/Patch burnout : The hardest thing about upgrading and patching isn’t the upgrading and patching itself. It’s the associated application testing. I know a lot of people who don’t bother with CPUs/PSUs, only focusing on patchsets. There are a lot of companies that can’t cope with a 4 yearly database release cycle. I can see people still choosing to do every 2, 3, 4 release. I hope this isn’t the case, but I fear it will be.
- Stability : The biggest thing people worry about is not new features. It’s stability and predictability of the database. One of our systems was upgraded from 188.8.131.52 to 184.108.40.206 over six months ago and we are still finding new issues. There are quarterly and yearly processes that keep cropping up with performance issues. There is a reason why a lot of people are still running old versions. If it ain’t broken, don’t fix it. My fear would be the quicker release cycle results in less stability from a response perspective, whether that’s because of bugs or features.
- Product Support/Certificaton : Two days ago someone told me they support their product on 220.127.116.11, but not 18.104.22.168 or 22.214.171.124. I’m not sure how software companies will deal with product certification on a quicker release cycle. I can imagine a few companies we work with biting their nails… 🙂
- Learning : The fanfare of a new version tends to focus people on learning the new stuff for a period of time. The second release seems to attract much less attention in that respect. I am interested to see how this new release cycle affects people. Will the drip feed of stuff make their life easier, or will people burn out and ignore them? It’s not like the Oracle database is the only thing I have to keep up to date with…
- Certification : We recently found out there is a 12cR2 certification exam. Ignoring 8.0 and 8.1, we’ve not really had a certification based on a release before. Maybe this is a one-off, but if the certification continues to be based on releases, does that mean we’ve got a certification exam each year from now on? I don’t see that is sustainable for most folks. What will happen for those people wanting to do OCM? 🙂 I guess the certification approach might need a rethink.
Like I said, this is all my idle ramblings. We will probably get something official soon that will make this all sounds stupid. 🙂 We now have the official information and I think all my concerns still stand.