etr2460 edited a comment on issue #12566: URL: https://github.com/apache/superset/issues/12566#issuecomment-762979550
Thanks for getting this doc out, I think it aligns with many of my hopes and dreams for a stable Superset and predictable version bumps. A few notes: There's no reference to function renaming or class refactoring in the breaking change section. I believe at this point we have some modules of code (specifically the Security Manager and the presto/hive jinja template code, although there might be others) where renaming functions/classes could be considered a breaking change to a public API. I'm not sure the best way to handle this, apart from adding CI checks on certain files to ensure that the structure of classes and functions remain the same in non-major versions. Note that this might also apply when changes to the TS plugins are made too. When discussing database migrations, the main consideration mentioned here is "time to run", but it doesn't address backwards compatibility of database migrations or push safety of db migrations. I'd recommend some additional guidelines for non-major changes: - Columns should not be renamed, and instead a new column with a new name should be added. An additional migration can remove the now unused column once all references to it are removed from code in a future release - Columns should not be deleted, unless all references to it are removed from code in a previous release This is mainly to ensure that when deploying db migrations in non-major versions, it can be done so without any downtime The note about putting breaking security changes into a minor release makes sense, but I'm a bit concerned that if someone is pinning their Superset release to the most recent minor release and automatically upgrading, then they won't notice the change. I might propose instead patching the current minor release with the breaking security fix and releasing it with a new major version number, then following up again with another major version. That way we maintain the meaning of semantic versions, even when security issues show up. Finally, I'm a bit concerned about the ability to keep PRs open and up to date with breaking changes in between the major versions. This might not be an issue if we expect a new major release every month or 2, but could be if there's 3-6 months in between major releases. Have we considered merging breaking changes into a seperate release branch once reviewed and having a release manager rebase this regularly? This would also allow people to stack multiple breaking changes on top of others, something that might be tricky with a bunch of PRs left open. Thanks for putting this SIP together, and I look forward to working with you and the rest of the community to enforce it and provide stable releases out of the box for our community! ---------------------------------------------------------------- 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]
