My proposal

is a “short life” release branch when hot fix needed, while master can still move on. It’s a modem practice in most software projects.

The branch can be created only when hot fix required, and it will be merged back to master once release out of the door.

And branch will “die” immediately for sprint release. While for “Lighthouse Release” , we will maintain it for a while , but strictly restrict only for security vulnerability fix.(3 months? I can’t recalled. @Tom.C)

Another idea & Cons:

I heard from Andrew about “short code freeze” (Dojo way ?)

It means: with a pre-condition of trustable nightly regression to ensure daily quality: on bi-Monday , if weekend traffic light is red, then we will “revert” to commit when last nightly regression is good, then release it.(to save the re-test time.)

It sounds great. But maybe not perfect suitable for RackHD for now. Reasons as below:

We don’t reach a trustable nightly regression ( or per-commit regression ) for now: There’re unstable test case failure from time to time. And CI infrastructure are still in dev stage .
Can we afford to release with “revert all commits” to last good date ? Especially for “lighthouse release”. Simply reverting may means “partial/incomplete features”.
If we don’t want to revert but a hot fix: then the “freeze” time may not be short (controlled in hours). And it’s unacceptable for modem agile model if master freeze for days.
How we handle with lighthouse release ? still no branch ?

Attachments

File Modified

No files shared here yet.

Browser not supported