It would be helpful for us to test third-party projects. But equally, it is useful for third-party projects to test against us. (Especially non-open-source ones, which we cannot test.) I strongly suggest that owners of those projects do a build and test against Calcite master about 3 weeks before a Calcite release. It gives us chance to address any regressions before the release.
> In HerdDB we saw regressions too late and the code was no more compatible > with Calcite master so we are still using a very old version of Calcite. I’ve seen that pattern often. It happened in Drill too, and they had to make Herculean efforts to get back onto the latest release. It’s in no one’s interests for dependent projects to slip behind. If the projects raise issues in at the right time (about 2 weeks before a release) we should endeavor to fix them. Julian > On Feb 9, 2020, at 6:13 AM, Enrico Olivelli <eolive...@gmail.com> wrote: > > Il Dom 9 Feb 2020, 08:41 Stamatis Zampetakis <zabe...@gmail.com> ha scritto: > >> Thanks for fixing the build Vladimir! >> >> I like the idea of testing against other projects on a weekly basis. It >> will certainly help detect regressions early on. It might be a bit hard to >> maintain since there could be failures quite often but I guess we will not >> know till we try. >> >> Even before adding 3rd-party projects in the CI, I would say that is worth >> running our integration tests (Druid, Cassandra, Postgres, etc.) > > > +1 > > I think that third party users should test their code against current > Calcite master and report to this list all problems as soon as possible. > > In HerdDB we saw regressions too late and the code was no more compatible > with Calcite master so we are still using a very old version of Calcite. > > We started to have a branch that builds and runs tests against Calcite > master. > Showstoppers in this process are when we break source/binary compatibility > in Calcite, so you have to maintain a separate branch, because you cannot > depend on SNAPSHOT release and this is expected to happen at every release. > > Having more frequent releases in Calcite would help a bit, but currently it > is not a big burden > > > Enrico > > at a >> regular basis by CI. I am checking them now and there seems to be again >> failures. >> >> Best, >> Stamatis >> >> >> >> On Sat, Feb 8, 2020 at 11:48 AM Vladimir Sitnikov < >> sitnikov.vladi...@gmail.com> wrote: >> >>>> Are current -SNAPSHOT packages on repository.apache.org up to date ? >>> >>> The snapshots were not up to date because Calcite-Snapshots Jenkins job >> was >>> using beam Jenkins node somehow. >>> I guess that was caused by misconfiguration of beam nodes. >>> >>> I've triggered the job manually, and it works now: >>> https://builds.apache.org/job/Calcite-Snapshots/ >>> On top of that, I've configured mails to dev@calcite list for the >>> snapshots >>> job so we'll know if it fails again. >>> >>>> I would like to test my projects in CI against current master >>> >>> I wonder if it makes sense to add GitHub Actions CI which would validate >>> third-party projects on a weekly basis. >>> For instance, I have https://github.com/vlsi/mat-calcite-plugin , which >> is >>> not that sophisticated, however, it would be nice to see >>> if the upcoming Calcite version is going to break or not that client. >>> >>> For instance, Beam has quite interesting post-commit tests page: >>> https://github.com/apache/beam#post-commit-tests-status-on-master-branch >>> >>> WDYT? >>> >>> Vladimir >>> >>
