4 ms·

> 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

by 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)?
- thayne 5y ago
  > No, because its unecessary (in my experience) Assuming that is true, this sounds like a normalcy bias to me (https://en.wikipedia.org/wiki/Normalcy_bias https://en.wikipedia.org/wiki/Normalcy_bias). > Why would you not want a new feature (e.g. the new "clone plugin") Because features can introduce bugs or performance regressions. Sure you can say that's rare, but I still might not want to take that risk with some of the most critical infrastructure in my app.

by thayne 5y ago

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)?

thayne 5y ago
> No, because its unecessary (in my experience) Assuming that is true, this sounds like a normalcy bias to me (https://en.wikipedia.org/wiki/Normalcy_bias https://en.wikipedia.org/wiki/Normalcy_bias). > Why would you not want a new feature (e.g. the new "clone plugin") Because features can introduce bugs or performance regressions. Sure you can say that's rare, but I still might not want to take that risk with some of the most critical infrastructure in my app.