eschutho commented on issue #12566: URL: https://github.com/apache/superset/issues/12566#issuecomment-764996515
> I think I was confused on what is "pinning at the latest minor version". I assumed it was like using `> 1.2.0 && < 2`, i.e. fixing to a major version and always automatically updates to the latest minor version. > > I was proposing to go straight to the major version, and release a minor/patch version that adds a deprecate warning, so that the release doesn't break things for users with autoupdates enabled and they would also know an upgrade is needed. If the fix is going to be a breaking change, we may not want it to be either a minor or patch release. Because according to Semantic Versioning, minor versions should always be backward compatible. > > The major version could either be straight from the `master` branch with the additional security fix or include only the security fix, depending on how stable `master` was at the time. (Hopefully stable enough with future continuous release...) Ok, I got you.. you're saying that security fixes with a breaking change should always go into the next release (similar to what @etr2460 suggested) as a major version. Security fixes that are backward compatible should go with the next release or as a patch on the last release. If the fix is backward compatible and the next release is a major version (as if the security issue was detected as we were building the next major version), then we should also backport the security fix to the last release as well. Did I get that correctly? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
