Makes sense to me. At some point if we have some PMC member(s) volunteering
to do maintenance on older releases, we shouldn't prohibit it. But I think
setting a general expectation that we only do maintenance releases of the
latest minor is pretty reasonable, especially given we've been pretty good
about keeping our compatibility contracts clean.

-Todd

On Wed, Feb 27, 2019 at 3:33 PM Adar Lieber-Dembo <[email protected]>
wrote:

> 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?
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Reply via email to