6 ms·

Many major new features have been introduced in 8.0 point releases. Some examples: * 8.0.12 added INSTANT algorithm for adding new columns to a table * 8.0.13

Many major new features have been introduced in 8.0 point releases. Some examples: * 8.0.12 added INSTANT algorithm for adding new columns to a table * 8.0.13 added DEFAULT expressions (column default values may now be any arbitrary expression, not just a constant) * 8.0.16 added CHECK constraints * 8.0.17 added the CLONE plugin for rapid physical copying of a db * 8.0.23 added INVISIBLE columns (excluded from SELECT *) These are just a handful among many others... basically MySQL 8 does not follow SemVer at all, nor does it claim to. (Although personally as a tool developer in the mysql ecosystem, I selfishly wish they did!)

dijit 5y ago
That’s pretty scary, isn’t it?
- evanelias 5y ago
  No, since MySQL 8 doesn't ever claim to use SemVer. They have an explicitly stated policy of including features in point releases. Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? SemVer is an arbitrary versioning scheme, not a universal standard. It's the operator's responsibility to understand the versioning scheme prior to upgrading.
  - dijit 5y ago
    I’m not saying semver is a universal standard but this is _wildly_ different to everything else. Nobody expects defaults to change between patch/minor versions. This is another example of how MySQL does not give a flying F about the footguns it leaves lying around. Putting the onus on the user is not reasonable; especially in a world where we’re trying to reduce toil or get rid of ops completely.
    - evanelias 5y ago
      In another subthread, you're (justifiably) unhappy with how they didn't change the strict-mode default soon enough; but here you're upset that some defaults changed too fast? Also my comment above in this subthread wasn't even about defaults. I only mentioned some features added, and you responded saying it's scary and then talking about defaults? You don't like MySQL, I get it. Regardless of reasons, I don't think your view will change, so why enter every HN thread about MySQL just to repetitively bash MySQL? What's the purpose of this?
      - dijit 5y ago
        The purpose, mainly is to warn people of the pain I’ve suffered. My life should be a lesson here because honestly it is _painful_ to realise you have lost monetary data and have to go hat in hand to the CTO and CFO to explain why. The strict mode setting should have been the default since the beginning. It is absolutely unthinkable that it wasn’t, the only justification I can think of is that: a) it wasn’t built with that in mind and thus was experimental. b) was not enabled to ease adoption (this is kinda evil, in my personal opinion because it teaches bad habits) c) was considered a power-user feature, which is ridiculous. What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns, and people who have bought into the ecosystem like to exhalt that “you’re holding it wrong”- which is absolutely not a good warning. If you listen to my rambling about the pain I’ve seen, and you still want to use it: at least it’s an informed decision. But pretending that all is well is not ideal, it doesn’t lead anyone to make better software or practices (MySQL) or better developers (because they don’t see footguns before they’ve sprung some self-inflicted wounds on themselves)
        evanelias 5y ago
        > The strict mode setting should have been the default since the beginning. I absolutely agree with that. But what's the point in talking about a terrible default that changed nearly 6 years ago, literally over and over again, year after year? > the only justification I can think of The real answer is almost certainly "backwards compatibility". Same reason many things in Windows are non-ideal, for example. Someone made a really bad technical decision early on, but fixing it overnight will break things for an utterly massive number of paying customers, so it can't be rectified without a slow transition plan. It happens. Yes, it absolutely should have been fixed on a faster schedule regardless, given its importance. But just because it wasn't, doesn't mean that the entirety of the piece of software is hopelessly flawed and everyone involved in its development is an utter cretin. Especially when a piece of software is multiple decades in age and has gone through multiple corporate acquisitions. > What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns What I've said? What footguns? I'm asking this honestly: what are you referring to? Let's recap this subthread: * @taywrobel said "it doesn't look like much new functionality has been introduced since 8.0.4" * I listed a number of new features introduced in 8.0 point releases, and explained that MySQL 8 is intentionally not doing SemVer * You said "that's pretty scary" without ever elaborating on which specific thing I said you find scary * I disagreed, given MySQL's stated written policy of not following SemVer * You mentioned something about defaults changing (??? this wasn't even a topic I mentioned by that point in the subthread) Now you're talking about footguns again, but the only one you're mentioning with any specificity was fixed many years ago. > people who have bought into the ecosystem like to exhalt that “you’re holding it wrong” Where has anyone said anything remotely like that in this subthread? Are you referring to my statement that the user should understand what's in an upgrade before upgrading? If so, I absolutely stand by that statement; it's utterly crazy to upgrade any database without even glancing at the release notes, let alone having a basic understanding of how the database vendor handles releases and versioning. This is operational basic practices 101, not about "holding it wrong". And for what it's worth, "people who have bought into the ecosystem" includes a massive chunk of the S&P500 using MySQL as a primary data store. If it's as deficient as you claim, why aren't all these companies going out of business?
    - bonzini 5y ago
      > _wildly_ different to everything else Linux?
      - dijit 5y ago
        Linux never changes backwards comparability. Linus is literally famous for saying as much.
    - buchanmilne 5y ago
      > Nobody expects defaults to change between patch/minor versions. Can you provide an example of an application-side (IOW, not a DB-infrastructure-type variable) that has changed it's default in a patch version after GA in 5.7 or 8.0? IIRC, all of the defaults changed in very early non-GA versions.
  - thayne 5y ago
    > Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? Is there another level of patches below point releases for backported security patches, or are your options to upgrade to something that adds new features and may be backwards incompatible, leave your system vulnerable to known security wholes, or patch it yourself (or maybe depend on your distro to do itl
    - evanelias 5y ago
      In practice, this is rarely a problem unless you're a cloud vendor with a DBaaS product; the most common concern there tends to be bugs that cause server crashes. But even that is fairly rare, and those platforms (AWS, GCP, Azure, Alibaba, etc) generally maintain custom patch sets anyway. As far as I can recall, the vast majority of modern MySQL CVEs have been low severity and/or require the attacker to already be in your private network. For sake of comparison -- does Postgres backport every security patch to every major.minor tree? And aren't HA Postgres upgrades generally more difficult than MySQL ones since logical replication is less widespread in the PG landscape?
      - anarazel 5y ago
        > For sake of comparison -- does Postgres backport every security patch to every major.minor tree? Unless the security fix in question is not applicable to some branch, yes. https://www.postgresql.org/support/security/ https://www.postgresql.org/support/security/ https://www.postgresql.org/support/versioning/ https://www.postgresql.org/support/versioning/
    - buchanmilne 5y ago
      > Is there another level of patches below point releases for backported security patches No, because its unecessary (in my experience) > or are your options to upgrade to something that adds new features and may be backwards incompatible It won't be backwards incompatible, otherwise they would leave the change for a new minor release. Why would you not want a new feature (e.g. the new "clone plugin") if it gives you value now without any migration required (because of incompatibilities that may arise if all new features are left for minor versions which are reserved for incompatibilities)?
  - throwdbaaway 5y ago
    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.

dijit 5y ago

That’s pretty scary, isn’t it?

evanelias 5y ago
No, since MySQL 8 doesn't ever claim to use SemVer. They have an explicitly stated policy of including features in point releases. Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? SemVer is an arbitrary versioning scheme, not a universal standard. It's the operator's responsibility to understand the versioning scheme prior to upgrading.
- dijit 5y ago
  I’m not saying semver is a universal standard but this is _wildly_ different to everything else. Nobody expects defaults to change between patch/minor versions. This is another example of how MySQL does not give a flying F about the footguns it leaves lying around. Putting the onus on the user is not reasonable; especially in a world where we’re trying to reduce toil or get rid of ops completely.
  - evanelias 5y ago
    In another subthread, you're (justifiably) unhappy with how they didn't change the strict-mode default soon enough; but here you're upset that some defaults changed too fast? Also my comment above in this subthread wasn't even about defaults. I only mentioned some features added, and you responded saying it's scary and then talking about defaults? You don't like MySQL, I get it. Regardless of reasons, I don't think your view will change, so why enter every HN thread about MySQL just to repetitively bash MySQL? What's the purpose of this?
    - dijit 5y ago
      The purpose, mainly is to warn people of the pain I’ve suffered. My life should be a lesson here because honestly it is _painful_ to realise you have lost monetary data and have to go hat in hand to the CTO and CFO to explain why. The strict mode setting should have been the default since the beginning. It is absolutely unthinkable that it wasn’t, the only justification I can think of is that: a) it wasn’t built with that in mind and thus was experimental. b) was not enabled to ease adoption (this is kinda evil, in my personal opinion because it teaches bad habits) c) was considered a power-user feature, which is ridiculous. What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns, and people who have bought into the ecosystem like to exhalt that “you’re holding it wrong”- which is absolutely not a good warning. If you listen to my rambling about the pain I’ve seen, and you still want to use it: at least it’s an informed decision. But pretending that all is well is not ideal, it doesn’t lead anyone to make better software or practices (MySQL) or better developers (because they don’t see footguns before they’ve sprung some self-inflicted wounds on themselves)
      - evanelias 5y ago
        > The strict mode setting should have been the default since the beginning. I absolutely agree with that. But what's the point in talking about a terrible default that changed nearly 6 years ago, literally over and over again, year after year? > the only justification I can think of The real answer is almost certainly "backwards compatibility". Same reason many things in Windows are non-ideal, for example. Someone made a really bad technical decision early on, but fixing it overnight will break things for an utterly massive number of paying customers, so it can't be rectified without a slow transition plan. It happens. Yes, it absolutely should have been fixed on a faster schedule regardless, given its importance. But just because it wasn't, doesn't mean that the entirety of the piece of software is hopelessly flawed and everyone involved in its development is an utter cretin. Especially when a piece of software is multiple decades in age and has gone through multiple corporate acquisitions. > What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns What I've said? What footguns? I'm asking this honestly: what are you referring to? Let's recap this subthread: * @taywrobel said "it doesn't look like much new functionality has been introduced since 8.0.4" * I listed a number of new features introduced in 8.0 point releases, and explained that MySQL 8 is intentionally not doing SemVer * You said "that's pretty scary" without ever elaborating on which specific thing I said you find scary * I disagreed, given MySQL's stated written policy of not following SemVer * You mentioned something about defaults changing (??? this wasn't even a topic I mentioned by that point in the subthread) Now you're talking about footguns again, but the only one you're mentioning with any specificity was fixed many years ago. > people who have bought into the ecosystem like to exhalt that “you’re holding it wrong” Where has anyone said anything remotely like that in this subthread? Are you referring to my statement that the user should understand what's in an upgrade before upgrading? If so, I absolutely stand by that statement; it's utterly crazy to upgrade any database without even glancing at the release notes, let alone having a basic understanding of how the database vendor handles releases and versioning. This is operational basic practices 101, not about "holding it wrong". And for what it's worth, "people who have bought into the ecosystem" includes a massive chunk of the S&P500 using MySQL as a primary data store. If it's as deficient as you claim, why aren't all these companies going out of business?
  - bonzini 5y ago
    > _wildly_ different to everything else Linux?
    - dijit 5y ago
      Linux never changes backwards comparability. Linus is literally famous for saying as much.
  - buchanmilne 5y ago
    > Nobody expects defaults to change between patch/minor versions. Can you provide an example of an application-side (IOW, not a DB-infrastructure-type variable) that has changed it's default in a patch version after GA in 5.7 or 8.0? IIRC, all of the defaults changed in very early non-GA versions.
- thayne 5y ago
  > Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? Is there another level of patches below point releases for backported security patches, or are your options to upgrade to something that adds new features and may be backwards incompatible, leave your system vulnerable to known security wholes, or patch it yourself (or maybe depend on your distro to do itl
  - evanelias 5y ago
    In practice, this is rarely a problem unless you're a cloud vendor with a DBaaS product; the most common concern there tends to be bugs that cause server crashes. But even that is fairly rare, and those platforms (AWS, GCP, Azure, Alibaba, etc) generally maintain custom patch sets anyway. As far as I can recall, the vast majority of modern MySQL CVEs have been low severity and/or require the attacker to already be in your private network. For sake of comparison -- does Postgres backport every security patch to every major.minor tree? And aren't HA Postgres upgrades generally more difficult than MySQL ones since logical replication is less widespread in the PG landscape?
    - anarazel 5y ago
      > For sake of comparison -- does Postgres backport every security patch to every major.minor tree? Unless the security fix in question is not applicable to some branch, yes. https://www.postgresql.org/support/security/ https://www.postgresql.org/support/security/ https://www.postgresql.org/support/versioning/ https://www.postgresql.org/support/versioning/
  - buchanmilne 5y ago
    > Is there another level of patches below point releases for backported security patches No, because its unecessary (in my experience) > or are your options to upgrade to something that adds new features and may be backwards incompatible It won't be backwards incompatible, otherwise they would leave the change for a new minor release. Why would you not want a new feature (e.g. the new "clone plugin") if it gives you value now without any migration required (because of incompatibilities that may arise if all new features are left for minor versions which are reserved for incompatibilities)?
- throwdbaaway 5y ago
  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.