> From the code-freeze point, to minimize the risk of delaying the > release, only bug fixes involving a regression of behavior compared to > a previous release should be allowed. Occasional exceptions will be > possible after higher scrutiny of the change.
It's a frequent point of discussion to debate which bug fixes are urgent enough to trigger a new RC candidate. I propose that we try to set guidelines now so that we can rely on them when issues come up. In my opinion, net new bugs that were introduced in the version should be fixed. Bugs that are not new, should not trigger a new RC, unless there is general consensus (however we define that) that the bug is sufficiently bad that we should trigger a new RC. If a bug is discovered during the RC testing period and it is not fixed, we should note this in the release notes for the version under a "known issues" section. This way, users of the impacted feature may decide to delay upgrading, while users that do not rely on the feature will have confidence upgrading. The main goal here is to ensure that we don't miss release deadlines, as Matteo just mentioned, and to give our users confidence when upgrading. Performance regressions are another issue that will arise. Dave Fisher has been working extensively on building out performance testing infrastructure to measure many Pulsar features. I expect that he (or someone else doing performance testing) will find degraded performance for some feature in the future. I think we should have a general rule of thumb that some percent regression (maybe 10%?) is serious enough to trigger a new RC. A percent might not be the only measure. If we have absolute metrics, like that a Pulsar cluster of x size must be able to handle y topics, that might be meaningful, too. What do others think? - Michael On Wed, Jun 8, 2022 at 2:26 PM Matteo Merli <matteo.me...@gmail.com> wrote: > > > Schedules always slip. Would you say that if the 3.x feature releases take > > too long with these hypothetical dates that 3.5 would be dropped in order > > to release 4.0 on schedule? > > Yes, there needs to be clarity for the users on when releases are to > be expected, even more so for LTS releases. And while it's true that > there are always delays, we have a lot that we can do to try to > minimize it. (eg: having a public deadline to hit will help in getting > everyone on the same page).
