I don't think having releases to fix critical bugs has any negative impact whatsoever on community. If anything, it shows we are willing to fix issues as fast as possible. Also, we should strive to get new releases out as soon as possible, there are great features and improvements coming in every release. I do think we should have a better testing process to expedite releases.
For example, take a look at Apache Spark: Spark 2.4.3 released (May 08, 2019) Spark 2.4.2 released (Apr 23, 2019) Spark 2.4.1 released (Mar 31, 2019) On Mon, May 13, 2019 at 12:04 PM Jihoon Son <ghoon...@gmail.com> wrote: > Slim, would you please elaborate more about your concern? > > The bug mentioned above is pretty serious. People might choose one of > versions between 0.14.0 and 0.14.1 depending on what type of DataSketch > they want to use. Theta sketch is not much useful in 0.14.1 while quantiles > sketch has a problem in 0.14.0. > If we found this bug earlier, it could be included in 0.14.1 which is best. > But the 0.14.1 release was already done when we found it and it was not > revertible. > Even though 0.15.0 release is also ongoing, the release process may take > several weeks to validate everything including potential bug fixes, invalid > license checking, and all voting processes. > If we don't release 0.14.2, then people should wait for 0.15.0 or find a > workaround for bugs in theta sketch or quantile sketch. > > We already mentioned that there is a known bug with theta sketch in the > release note of 0.14.1, people should notice that bug and decide what > versions they would upgrade to. If they don't care about the sketch bugs, > then they can use any version. > > Jihoon > > On Fri, May 10, 2019 at 12:17 PM Gian Merlino <g...@apache.org> wrote: > > > I hope for 0.15.0 we can get more people to install the release > candidates > > in production -- I think probably a lot of people wait for a final > release > > before doing that, but the additional testing really helps. At Imply we > > definitely have additional stress testing planned (in fact we've already > > installed the 0.15.0-incubating branch in _our_ production environment > and > > have started to bang on it). The more of that we can get, the better, > > especially since not all sites use all features, so you need a few sites > to > > get good coverage. > > > > On Fri, May 10, 2019 at 10:36 AM Slim Bouguerra <bs...@apache.org> > wrote: > > > > > It sounds like we are doing release after release with out enough time > to > > > validate candidates, in the long run this might hurt adoption. > > > > > > On Fri, May 10, 2019 at 08:44 Gian Merlino <g...@apache.org> wrote: > > > > > > > It sounds like a plan to me. > > > > > > > > On Thu, May 9, 2019 at 6:53 PM Clint Wylie <cwy...@apache.org> > wrote: > > > > > > > > > I know 0.14.1-incubating just released, and the 0.15.0-incubating > > > branch > > > > > has already been cut, but > > > > > https://github.com/apache/incubator-druid/issues/7607 which was > > > > introduced > > > > > in 0.14.1-incubating seems like a pretty ugly issue, so I'm > throwing > > > > > together a 0.14.2-incubating with the fix and a couple of other bug > > > fixes > > > > > for result level cache. > > > > > > > > > > fixes: > > > > > https://github.com/apache/incubator-druid/pull/7619 > > > > > https://github.com/apache/incubator-druid/pull/7614 > > > > > https://github.com/apache/incubator-druid/pull/7624 > > > > > > > > > > I think the turn around on getting 0.14.2-incubating out might be a > > lot > > > > > quicker than the timespan it will take us to validate, finalize, > and > > > vote > > > > > on 0.15.0-incubating. > > > > > > > > > > Thanks, > > > > > Clint > > > > > > > > > > > > > > >
