michellethomas commented on issue #6131: [SIP-12] Proposal for Branch Management and Release Process URL: https://github.com/apache/incubator-superset/issues/6131#issuecomment-445004118 Superset Deployment Process Update Sticking to a schedule of a deployment every two weeks has been challenging, and @mistercrunch proposed another schedule that is slightly more flexible and would allow for more time for bug fixing. When we sort out what we need to do to consider these valid releases by ASF standards, we can start trying out this process. Proposed process: 1. Always cut on Monday (rc0 and release). If it is a public holiday, postpone to the next business day. Take a week for testing and bug fixing 2. Cherry pick bug fixes for rc1. a. Decide if the release is stable enough to deploy. A release would be stable if it has no known major regressions or new bugs blocking critical functionality. b. If not: i) If there’s something blocking the release that’s easy to revert, we’ll revert it ii) Go back to step 2 for rc2 3. At week 2 if it is not releasable, identify the main blocking issues 4. At week 3 revert the blockers if not resolved and start a [Vote] email 5. Tag the release as release 1.1 6. Continue to fix bugs on this release until the next release goes out.  We’ll cut 1.1.0 two weeks after 1.0.0 is cut, and go through the same process. There should not be more than two branches open at a time so 1.2.0 will not be cut until the following Monday after 1.0.0 goes out. If maintaining two branches is too complicated, we may just have one. A branch shouldn’t take more than 4 weeks to be released because blockers should be reverted at week 3. The goals of this process - Those involved in feature development have enough time to find, and triage issues. Ideally all contributors would be deploying these changes to a test environment and looking for issues. - There’s enough time so that whoever introduced the regression can address it. They should be communicating with whoever cut the branch when they expect the bug to be fixed. By default the person cutting the branch will not be responsible for fixing all bugs for a deployment, and contributors should maintain ownership of the successful deployment of their features. If a bug does not get fixed in 4 weeks, the feature will be reverted. - There’s a regular structure and clear process so that we all can efficiently and regularly make deployments. Through this process committers should: - Use a “risk:xxx” tag to mark PRs that need thorough testing. Things that may require “risk” tag: db_migration, large feature, or changing large or brittle sections of code. - Tag PRs with the release they should go to - Tag issues as a bug and which release(s) the bug is in CC: @john-bodley @kristw
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
