Replies: 1 comment 1 reply
-
Hi @Anton12! I'm Dosu and I’m helping the superset team. Superset uses a structured release process documented in the Release Process wiki and RELEASING/README.md. Major releases (like v5.0.0) are planned via Superset Improvement Proposals (SIPs), Kanban boards, and a release schedule. Breaking changes are proposed, discussed, and require consensus on the dev@ mailing list with a 3-day objection window. Final releases are validated using Apache's voting process, which requires at least 3 binding votes and a 72-hour window. Superset follows Semantic Versioning: major releases (e.g., v4, v5) can include breaking changes such as CLI/API changes, config flag removals, destructive database migrations, UI removals, permission changes, and dependency upgrades. Minor and patch releases aim for backward compatibility. Branches for each major.minor version (like 4.1, 5.0) are cut from master at a specific point. Patch releases are made by cherry-picking PRs labeled for that version into the release branch, not by merging master. This means master, 4., and 5. can diverge significantly, which is why you see large diffs and why branches like The For explicit differences between v4 and v5, you can check the CHANGELOG and UPDATING.md for each release. For example, v5.0.0 includes fixes for several CVEs not present in v4, and v4.1.3 includes a fix for a CVE not present in earlier 4.x releases. Only the latest minor of the last two major versions is supported at any time; when a new major is released, support for the oldest is dropped. Critical fixes may be excluded from older branches if cherry-picking is complex. If you need more detail on a specific breaking change or migration, let me know! To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Is there are readme or other docs about release procedure and the version compliance for Superset?
How developers make a desigion about new release and release tag?
Is there are any approve procedure new tags creation?
Based on commits tree is not cleare correlation of code with 5./4 versions and master branch.
I'm not understand why origin/4.1 (for tag 4.1.3) and origin/ephenv-for-5.0.0rc4 (for tag 5.0.0) not merged in master and have too many diffs with each other.
Seems we have 3 different product lines (master, 4.* and 5.*) because I need to use a SUPERSET_APP_ROOT variable (in master) but it's not included in code of latest releases.
Beta Was this translation helpful? Give feedback.
All reactions