I lean towards the option to do 2 releases. Operators can feel more confident about stability of 0.21.0 if their upgrade is coming up.
If we choose to do multiple releases - To avoid operators having to upgrade large clusters twice in close proximity, we should do our best to communicate the rough ETA on 0.22.0 since it will be out of step with the usual delay between releases. That way they can decide to wait it out for 0.22.0 if that works better for them. - Lucas On Wed, Mar 31, 2021 at 12:43 PM Jihoon Son <jihoon...@apache.org> wrote: > Hi all, > > The 0.21.0 release has been blocked by several issues for a long time > including 2 security vulnerabilities (CVE-2021-25646 and > CVE-2021-26919 which are addressed in 0.20.1 and 0.20.2, > respectively). Since we created the release branch for 0.21.0 on > January 11th, it is almost the time to prepare the next release (the > next branch cut is scheduled in April). If we stick to the schedule > and prepare another release right after 0.21.0, it will not be great > for our users because they won't have enough time to test out the > 0.21.0 release. I think we have 2 options to avoid this issue: > > - Consolidating the 0.21.0 and 0.22.0 releases. We can create one > release that will contain all commits that are originally scheduled to > be released separately via 0.21.0 and 0.22.0. > - Finalizing the 0.21.0 release quickly and postponing the 0.22.0 > release e.g., a month. > > To me, the second option seems more reasonable because of the below > reasons. > > - The 0.21.0 release is almost ready. We can finish it quickly without > much further preparation. > - There are users waiting for the features introduced in 0.21.0. > Consolidating 2 releases will make them wait longer. > - There could be unknown bugs in the release branch. Consolidating > releases will make testing harder since it will increase the scope of > testing. > - Consolidating releases will remove one option for users what release > they can use. This can be problematic especially when some bugs are > found in the new release. > > I'd like to hear what other people think. > > Thanks, > Jihoon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org > For additional commands, e-mail: dev-h...@druid.apache.org > >
