16 ms·

It is pretty scary because most of these new features or enhancements are buggy. By not adopting SemVer, users of MySQL who prefer stability (oxymoron?) have no

It is pretty scary because most of these new features or enhancements are buggy. By not adopting SemVer, users of MySQL who prefer stability (oxymoron?) have no obvious upgrade path. They could be happily using version 8.0.123, and then upgrade to version 8.0.126 to get some security fix, and suddenly encounter a bunch of functionality and/or performance regressions. Some examples... WL#10310 Redo log optimization: Feb 2018, initial commit 6be2fa0bdbba, landed in 8.0.11 (Apr 2018) Jun 2018, crash regression fix commit 270d18368650, landed in 8.0.13 (Oct 2018) Apr 2019, performance regression fix commit 75c4f7161a56, landed in 8.0.18 (Oct 2019) WL#5655 - InnoDB: Separate doublewrite file to ensure atomic writes: Dec 2019, initial commit ce14ef911, landed in 8.0.20 (Apr 2020) Feb 2020, data loss regression fix commit c1bc61dc7, landed in 8.0.20 (Apr 2020) May 2020, stall regression fix commit 00b284707, landed in 8.0.21 (Jul 2020) In comparison, Cassandra during the DataStax days was extremely buggy, but at least it tried to follow SemVer. So the operators can follow some simple guideline, e.g. >=2.0.14 is fine, >=2.1.17 is fine, >=2.2.9 is fine. Of course regression can still happen, but that would be an exceptional case.

kaba0 5y ago
This is a misconception that new features introduce more bugs than eg. patches/minor version upgrades. I can only bring up the OpenJDK project as example but this sort of change happened there as well - what used to be JDK 8.xxx and everyone jumped to that without second thought is the exact same thing as JDK 9->10. It’s just management’s backwards thinking that somehow the former is safe to apply while the latter is not.
- throwdbaaway 5y ago
  There is certainly no hard and fast rule. In the JDK case, in terms of language design, my observation is that with Brian Goetz in charge, it doesn't matter too much whether it was the slow release cycle back in the pre-9 days, or the shorter one from JDK 9 onward -- whenever a new feature is introduced, all kinds of compatibilities are being maintained at all costs. (Except Project Jigsaw of course, but I'd like to think that he got overruled by his boss) As for bugs, I will just quote Gil Tene from https://www.theserverside.com/opinion/Dont-ever-put-a-non-Java-LTS-release-into-production https://www.theserverside.com/opinion/Dont-ever-put-a-non-Ja... > Play with them on your laptop, but don't use a single feature, and wait for the LTS. Personally I think the LTS model is great. Features get rolled out as soon as they are ready, and then get stabilized after being used by early adopters. Meanwhile, production can stay on LTS and continue to get just the necessary fixes.
evanelias 5y ago
In my experience, it is quite an exaggeration to claim that "most" post-GA 8.0 features or enhancements are buggy, especially in the general case. Yes, some of them may have edge-case bugs or performance issues, but typically only affecting some users with very specific environmental or workload situations. Operators must test before upgrading. Luckily some third-party software makes this easier, e.g. Percona's pt-upgrade or ProxySQL's mirroring feature. I'll state again unambiguously, I'm not personally fond of 8.0's release policy of rolling out new features post-GA. But I view it as an annoyance, and at least one with some upsides (not having to wait 2 years for a massive feature dump all at once) rather than being uniformly negative or "pretty scary". Personally I was careful about testing point release upgrades before 8.0, and I'm still careful about it now.

kaba0 5y ago

This is a misconception that new features introduce more bugs than eg. patches/minor version upgrades. I can only bring up the OpenJDK project as example but this sort of change happened there as well - what used to be JDK 8.xxx and everyone jumped to that without second thought is the exact same thing as JDK 9->10. It’s just management’s backwards thinking that somehow the former is safe to apply while the latter is not.

throwdbaaway 5y ago
There is certainly no hard and fast rule. In the JDK case, in terms of language design, my observation is that with Brian Goetz in charge, it doesn't matter too much whether it was the slow release cycle back in the pre-9 days, or the shorter one from JDK 9 onward -- whenever a new feature is introduced, all kinds of compatibilities are being maintained at all costs. (Except Project Jigsaw of course, but I'd like to think that he got overruled by his boss) As for bugs, I will just quote Gil Tene from https://www.theserverside.com/opinion/Dont-ever-put-a-non-Java-LTS-release-into-production https://www.theserverside.com/opinion/Dont-ever-put-a-non-Ja... > Play with them on your laptop, but don't use a single feature, and wait for the LTS. Personally I think the LTS model is great. Features get rolled out as soon as they are ready, and then get stabilized after being used by early adopters. Meanwhile, production can stay on LTS and continue to get just the necessary fixes.

evanelias 5y ago

In my experience, it is quite an exaggeration to claim that "most" post-GA 8.0 features or enhancements are buggy, especially in the general case. Yes, some of them may have edge-case bugs or performance issues, but typically only affecting some users with very specific environmental or workload situations. Operators must test before upgrading. Luckily some third-party software makes this easier, e.g. Percona's pt-upgrade or ProxySQL's mirroring feature. I'll state again unambiguously, I'm not personally fond of 8.0's release policy of rolling out new features post-GA. But I view it as an annoyance, and at least one with some upsides (not having to wait 2 years for a massive feature dump all at once) rather than being uniformly negative or "pretty scary". Personally I was careful about testing point release upgrades before 8.0, and I'm still careful about it now.