v0.8.20

Built against Mojo 1.0.0 (ed45d567).

A patch release. The entry that matters is the version number itself, and one more statement of the DuckDB dialect reads at the parse.

The version number

firepanda/version.mojo carries a note saying that the version lives in three files and that three copies which can drift will. It then drifted twice running.

              pixi.toml   pyproject.toml   version.mojo
0.8.18          0.8.18           0.8.17         0.8.17
0.8.19          0.8.19           0.8.17         0.8.17
0.8.20          0.8.20           0.8.20         0.8.20

So firepanda.version() has been reporting two releases behind the one it was built from, and a wheel cut from either of those commits would have carried the same wrong number. If you are pinning a build by what the library reports about itself rather than by the tag, 0.8.18 and 0.8.19 both say 0.8.17 and this is the first release where the answer is right.

All three read 0.8.20 now, and the spec job compares them on every run. Nothing in the build derives any of them from the tag, so a check is the only thing that would notice, and the note in version.mojo had already said what happens without one.

The dialect

IN over a bare value reads as the containment it is, rather than being turned down at the parse. The right side is usually a list or a map, so what stops it now is that contains has no kernel yet rather than anything about how the query was spelled.

Nothing else moves

No API changes and no answer changes from 0.8.19.