A recent Slack discussion revealed that we may not have consensus on how our project handles backports to older branches. This e-mail is an attempt to build that consensus; please weigh in if you have an opinion.
Perhaps it's best to start from first principles: when release x.y is the latest released version of Kudu, and release x.y+1 is under development, for which of all x.a (where a<y+1) releases do we expect to see maintenance releases? In theory, any PMC member can kick off a release of any version they choose. In practice, we've only done maintenance releases for a handful of minors, and never more than one maintenance release. So I think there's rough consensus that when x.y+1 is under development, we're only supporting possible maintenance releases for x.y. Put more simply, we should prepare for possible maintenance releases only for the latest release of Kudu. Here's a strawman backport policy: only backport to branches where we expect possible maintenance releases. Currently, 1.8.0 is the latest minor release, so we should actively backport to branch-1.8.x until 1.9.0 is released, at which point branch-1.9.x becomes the backport target and branch-1.8.x is, for all intents and purposes, dead. What sorts of patches merit backporting? Off the top of my head: - Fixes that keep CI working (e.g. pinning of unpinned Python dependencies that break). - Fixes to security vulnerabilities. - Data loss fixes. - Performance fixes, provided the impact:risk ratio is very high. What do you think?
