You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Ruben Q L <ru...@gmail.com> on 2020/10/01 07:04:45 UTC
Re: [DISCUSS] Towards Calcite 1.26.0
FYI, AppVeyor issue has been resolved.
Thanks Julian and Vladimir for your help!
On Wed, Sep 30, 2020 at 7:32 PM Julian Hyde <jh...@gmail.com> wrote:
>
>
> > PS. I wonder what everybody think of
> > https://github.com/apache/calcite/pull/2182 (enable error-prone
> > verifications)
>
> I’m in favor it, but since it’s a large change (and therefore potential
> for merge conflicts), timing will be important. Early in 1.27 is probably
> the best timing.
>
> Julian
>
>
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Ruben Q L <ru...@gmail.com>.
Thanks for the answer Danny.
If I am not mistaken, CALCITE-2569 and CALCITE-3923 were released with
1.25.0 (not 1.26.0), and were correctly flagged as breaking changes in the
previous release's breaking changes section.
Best,
Ruben
On Sun, Oct 4, 2020 at 3:16 AM Danny Chan <yu...@gmail.com> wrote:
> AFAIK,
>
> • CALCITE-4279: the SEARCH operator is a new one and causes the RexNode
> tree change which is breaking because downstream projects need to adapter
> for it
> • CALCITE-2569: the UDF needs to implement a new interface SqlTableFunction
> • CALCITE-3923: many singletons are removed and breaking
>
>
> Best,
> Danny Chan
> 在 2020年10月3日 +0800 AM1:12，Ruben Q L <ru...@gmail.com>，写道：
> > I'm working on the release notes, any breaking change worth mentioning
> > apart from https://issues.apache.org/jira/browse/CALCITE-2082 ?
> >
> >
> > On Fri, Oct 2, 2020 at 11:59 AM Ruben Q L <ru...@gmail.com> wrote:
> >
> > > Thanks for the answer Vladimir.
> > > ----
> > >
> > > I have a tight schedule today. I hope to generate a RC0 today or worst
> > > case scenario tomorrow.
> > >
> > > Best,
> > > Ruben
> > >
> > >
> > > On Fri, Oct 2, 2020 at 11:47 AM Vladimir Sitnikov <
> > > sitnikov.vladimir@gmail.com> wrote:
> > >
> > > > Ruben>Could someone that has recently built a release using the new
> > > > gradle-based
> > > > Ruben>process confirm this point?
> > > >
> > > > oh, that was a question by Ruben, and I copy-pasted the wrong name :)
> > > >
> > > > Vladimir
> > > >
> > >
>
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Danny Chan <yu...@gmail.com>.
AFAIK,
• CALCITE-4279: the SEARCH operator is a new one and causes the RexNode tree change which is breaking because downstream projects need to adapter for it
• CALCITE-2569: the UDF needs to implement a new interface SqlTableFunction
• CALCITE-3923: many singletons are removed and breaking
Best,
Danny Chan
在 2020年10月3日 +0800 AM1:12，Ruben Q L <ru...@gmail.com>，写道：
> I'm working on the release notes, any breaking change worth mentioning
> apart from https://issues.apache.org/jira/browse/CALCITE-2082 ?
>
>
> On Fri, Oct 2, 2020 at 11:59 AM Ruben Q L <ru...@gmail.com> wrote:
>
> > Thanks for the answer Vladimir.
> > ----
> >
> > I have a tight schedule today. I hope to generate a RC0 today or worst
> > case scenario tomorrow.
> >
> > Best,
> > Ruben
> >
> >
> > On Fri, Oct 2, 2020 at 11:47 AM Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com> wrote:
> >
> > > Ruben>Could someone that has recently built a release using the new
> > > gradle-based
> > > Ruben>process confirm this point?
> > >
> > > oh, that was a question by Ruben, and I copy-pasted the wrong name :)
> > >
> > > Vladimir
> > >
> >
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Ruben Q L <ru...@gmail.com>.
I'm working on the release notes, any breaking change worth mentioning
apart from https://issues.apache.org/jira/browse/CALCITE-2082 ?
On Fri, Oct 2, 2020 at 11:59 AM Ruben Q L <ru...@gmail.com> wrote:
> Thanks for the answer Vladimir.
> ----
>
> I have a tight schedule today. I hope to generate a RC0 today or worst
> case scenario tomorrow.
>
> Best,
> Ruben
>
>
> On Fri, Oct 2, 2020 at 11:47 AM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
>> Ruben>Could someone that has recently built a release using the new
>> gradle-based
>> Ruben>process confirm this point?
>>
>> oh, that was a question by Ruben, and I copy-pasted the wrong name :)
>>
>> Vladimir
>>
>
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Ruben Q L <ru...@gmail.com>.
Thanks for the answer Vladimir.
----
I have a tight schedule today. I hope to generate a RC0 today or worst case
scenario tomorrow.
Best,
Ruben
On Fri, Oct 2, 2020 at 11:47 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Ruben>Could someone that has recently built a release using the new
> gradle-based
> Ruben>process confirm this point?
>
> oh, that was a question by Ruben, and I copy-pasted the wrong name :)
>
> Vladimir
>
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Vladimir Sitnikov <si...@gmail.com>.
Ruben>Could someone that has recently built a release using the new
gradle-based
Ruben>process confirm this point?
oh, that was a question by Ruben, and I copy-pasted the wrong name :)
Vladimir
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Vladimir Sitnikov <si...@gmail.com>.
Vladimir>Could someone that has recently built a release using the new
gradle-based
Vladimir>process confirm this point?
I developed Gradle-based scripts, and one of the intentions was that no
commits should be made during the release.
No commits required to switch "release-snapshot" versions as well.
In other words, you get Git tree to the way you like it (e.g. update
release notes, fix tests, etc), then you prepare RC and Release
artifacts from exactly the same Git sha.
Vladimir
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Ruben Q L <ru...@gmail.com>.
Thanks for the answer Stamatis.
Could someone that has recently built a release using the new gradle-based
process confirm this point?
Thanks
Ruben
On Fri, Oct 2, 2020 at 10:42 AM Stamatis Zampetakis <za...@gmail.com>
wrote:
> Hi Ruben,
>
> If I remember well, you should commit them under CALCITE-4291 and then
> proceed with the release.
>
> Best,
> Stamatis
>
> On Fri, Oct 2, 2020 at 11:06 AM Ruben Q L <ru...@gmail.com> wrote:
>
> > Hello,
> >
> > thanks everyone for your effort pushing the remaining issues forward.
> > We enter a code freeze in order to generate a RC0 for 1.26.0, so please
> DO
> > NOT commit into master until further notice.
> >
> > To our expert release managers, I have a stupid question about "how-to
> > making a release candidate" instructions [1]:
> > The changes that I need to "check" and "add" (README,
> > site/_docs/history.md, site/_docs/howto.md), do I need to commit those
> > changes myself before starting the RC0 generation process; or I just need
> > to make those changes locally, leave them uncommitted, because they will
> > get automatically committed during the RC generation (or publication)
> > process?
> >
> > Best regards,
> > Ruben
> >
> > [1]
> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> >
> >
> > On Thu, Oct 1, 2020 at 8:04 AM Ruben Q L <ru...@gmail.com> wrote:
> >
> > > FYI, AppVeyor issue has been resolved.
> > > Thanks Julian and Vladimir for your help!
> > >
> > > On Wed, Sep 30, 2020 at 7:32 PM Julian Hyde <jh...@gmail.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> > PS. I wonder what everybody think of
> > >> > https://github.com/apache/calcite/pull/2182 (enable error-prone
> > >> > verifications)
> > >>
> > >> I’m in favor it, but since it’s a large change (and therefore
> potential
> > >> for merge conflicts), timing will be important. Early in 1.27 is
> > probably
> > >> the best timing.
> > >>
> > >> Julian
> > >>
> > >>
> >
>
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Stamatis Zampetakis <za...@gmail.com>.
Hi Ruben,
If I remember well, you should commit them under CALCITE-4291 and then
proceed with the release.
Best,
Stamatis
On Fri, Oct 2, 2020 at 11:06 AM Ruben Q L <ru...@gmail.com> wrote:
> Hello,
>
> thanks everyone for your effort pushing the remaining issues forward.
> We enter a code freeze in order to generate a RC0 for 1.26.0, so please DO
> NOT commit into master until further notice.
>
> To our expert release managers, I have a stupid question about "how-to
> making a release candidate" instructions [1]:
> The changes that I need to "check" and "add" (README,
> site/_docs/history.md, site/_docs/howto.md), do I need to commit those
> changes myself before starting the RC0 generation process; or I just need
> to make those changes locally, leave them uncommitted, because they will
> get automatically committed during the RC generation (or publication)
> process?
>
> Best regards,
> Ruben
>
> [1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate
>
>
> On Thu, Oct 1, 2020 at 8:04 AM Ruben Q L <ru...@gmail.com> wrote:
>
> > FYI, AppVeyor issue has been resolved.
> > Thanks Julian and Vladimir for your help!
> >
> > On Wed, Sep 30, 2020 at 7:32 PM Julian Hyde <jh...@gmail.com>
> > wrote:
> >
> >>
> >>
> >> > PS. I wonder what everybody think of
> >> > https://github.com/apache/calcite/pull/2182 (enable error-prone
> >> > verifications)
> >>
> >> I’m in favor it, but since it’s a large change (and therefore potential
> >> for merge conflicts), timing will be important. Early in 1.27 is
> probably
> >> the best timing.
> >>
> >> Julian
> >>
> >>
>
Re: [DISCUSS] Towards Calcite 1.26.0
Posted by Ruben Q L <ru...@gmail.com>.
Hello,
thanks everyone for your effort pushing the remaining issues forward.
We enter a code freeze in order to generate a RC0 for 1.26.0, so please DO
NOT commit into master until further notice.
To our expert release managers, I have a stupid question about "how-to
making a release candidate" instructions [1]:
The changes that I need to "check" and "add" (README,
site/_docs/history.md, site/_docs/howto.md), do I need to commit those
changes myself before starting the RC0 generation process; or I just need
to make those changes locally, leave them uncommitted, because they will
get automatically committed during the RC generation (or publication)
process?
Best regards,
Ruben
[1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate
On Thu, Oct 1, 2020 at 8:04 AM Ruben Q L <ru...@gmail.com> wrote:
> FYI, AppVeyor issue has been resolved.
> Thanks Julian and Vladimir for your help!
>
> On Wed, Sep 30, 2020 at 7:32 PM Julian Hyde <jh...@gmail.com>
> wrote:
>
>>
>>
>> > PS. I wonder what everybody think of
>> > https://github.com/apache/calcite/pull/2182 (enable error-prone
>> > verifications)
>>
>> I’m in favor it, but since it’s a large change (and therefore potential
>> for merge conflicts), timing will be important. Early in 1.27 is probably
>> the best timing.
>>
>> Julian
>>
>>