I still don't see why doing another release is harmful. People would have one more option of trying 0.14.2 immediately instead of waiting for 0.15.0. Why would we make them to wait for 0.15.0?
Also, we don't have to release for every bug fix, but we should do for regression bugs. This is a regression bug which prevents users to upgrade from 0.14.0 to 0.14.1 since it didn't exist in 0.14.0. Suppose someone faced a bug while he's using 0.14.0 which is fixed in 0.14.1. However, he might still not be able to upgrade to 0.14.1 because of this theta sketch bug. As you said, Druid is a sort of database management system and is not easy to upgrade. Since he is already using 0.14.0, upgrading to 0.14.2 is much easier option rather than waiting for 0.15.0, and then evaluating and testing it again. Jihoon On Mon, May 13, 2019 at 6:41 PM Slim Bouguerra <bs...@apache.org> wrote: > @Jihoon, > As i said if you are a cluster operator and you have a long running > critical service why would you not wait couple of week, IMO this is not a > very critical bug and i don't think it is sustainable to do a release on > every bug. > The question how many cluster this issue is really affecting? and is > releasing a new version is really the best solution? > > @Fangjin Yang <fang...@imply.io> > Fixing the bug and releasing are totally different things in my opinion. > Again Spark is not a long running as database storing critical data and > operated as a cluster serving multiple users IMO Spark is the perfect > example of library that you deploy then you tear down. > > > On Mon, May 13, 2019 at 1:53 PM Fangjin Yang <fang...@imply.io> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
