It was indeed a regression, but it didn’t break any of Calcite’s tests and no one spoke up during the release vote. Mistakes are expensive to fix after a release, cheaper during the release vote, and cheapest of all if found by the test suite.
> On Mar 5, 2023, at 6:33 AM, Charles Givre <[email protected]> wrote: > > That would be great! Again I’m only asking because this was a regression. > I really do appreciate it. Thanks! > > Sent from my iPhone > >> On Mar 4, 2023, at 13:59, Stamatis Zampetakis <[email protected]> wrote: >> >> If we get the 1.34.0 out a bit sooner than usual I guess this will be good >> enough for Drill. If the others agree I can try to prepare an RC during >> next week. WDYT ? >> >> Best, >> Stamatis >> >> >>> On Sat, Mar 4, 2023, 6:13 PM Alessandro Solimando < >>> [email protected]> wrote: >>> >>> The second option Benchao mentions is what Hive currently does as well. >>> >>> Best regards, >>> Alessandro >>> >>>>> On Sat 4 Mar 2023, 13:19 Benchao Li, <[email protected]> wrote: >>>>> >>>>> Hi Charles, >>>>> >>>>> Thank for reaching out! >>>>> >>>>> IIRC, the idea of releasing bugfix version has been brought up in the >>> past, >>>> but I couldn't find the discussion (in Jira and dev ML). >>>> >>>> I'd like to share my understanding why we chose not to release bug fix >>>> versions, please correct me if I'm wrong, >>>> - Calcite has many bug fixes that span multi versions (even more that 10 >>>> versions), then only keeping several (such as 3) bug fix releases does >>> not >>>> solve all these problems. >>>> - Actually we usually do not distinguish too much between "bugfix" and >>> "new >>>> feature", so maintaining bug fix releases is not that easy. >>>> - Calcite lacks reviewers and also release managers, only keeping linear >>>> releasing in rhythm could save us some efforts. >>>> >>>> For regressions, I agree that this hurts downstream projects. For such >>>> cases, there are two approaches come into my mind: >>>> - We can release a new version quickly than usual. >>>> - The projects that need the fix/feature before our next scheduled >>> release, >>>> they could copy these files into their projects, as we already did in >>>> Flink[1]. They could remove these files once they adopt the new release >>> of >>>> Calcite. >>>> >>>> I hope this helps. >>>> >>>> [1] >>>> >>>> >>> https://github.com/apache/flink/tree/master/flink-table/flink-table-planner/src/main/java/org/apache/calcite >>>> >>>> >>>> Charles Givre <[email protected]> 于2023年3月2日周四 06:22写道： >>>> >>>>> Hello Calcite Devs, >>>>> I wanted to thank everyone for the recent release of Calcite 1.33. I >>> am >>>>> the PMC Chair for Apache Drill and we just released Drill 1.21[0] which >>>> is >>>>> now using the latest version of Calcite instead of our 2-3 year old >>> fork! >>>>> >>>>> However, we encountered a small issue with Calcite 1.33 that does not >>>>> affect just Drill. Specifically, there was a regression which was >>> caused >>>>> by CALCITE-5447[1] which effectively broke the DATE_TRUNC function. >>> The >>>>> bugfix has been fixed and merged in CALCITE-5522[2]. >>>>> >>>>> In any event, given that this function is fairly important and the >>>> lengthy >>>>> release schedules of both Drill and Calcite, I wanted to ask whether >>> the >>>>> Calcite might consider doing a quick bugfix release with this and any >>>> other >>>>> regressions that may have popped up in 1.33 and have since been fixed. >>>>> >>>>> Thank you very much for all your work! >>>>> Best, >>>>> -- Charles >>>>> >>>>> >>>>> [0]: >>>>> >>>> >>> https://github.com/apache/drill-site/blob/master/blog/_posts/en/2023-02-21-drill-1.21.0-released.md >>>>> [1]: https://issues.apache.org/jira/browse/CALCITE-5447 >>>>> [2]: https://issues.apache.org/jira/browse/CALCITE-5522 >>>> >>>> >>>> >>>> -- >>>> >>>> Best, >>>> Benchao Li >>>> >>>
