Now that some people are actually using PRQL, we should decide how to do releases.

Principles

• Low release latency. When someone makes a change, that should flow to users quickly — it's good for users and encouraging for contributors. There's very little weighing on the side of releasing slower — we have extensive tests, we can always roll-back if we make a mistake, no one is relying on it for production.
• Automated. Can we make this as automated as possible?

Tagging

We have the advantage of a monorepo (except for dbt-prql & pyprql, for their own reasons), but it means that it might too broad to just version everything based on a single unified repo tag; at least for patch versions — what do others think?

The upside is that it's very simple. The downside is that if we make a change to only prql-python and want to do a release, we get a new version of prql-compiler with zero changes. That would weigh more if we had something like dbt-prql here, because it's more than just a binding for prql-compiler.

Automation

• @rbpatt2019 & @charlie-sanders have set up some quite impressive automation in pyprql. It a bit heavier duty — each commit is labeled with whether it's a breaking change or not, and then it works out what version to use — but very manageable. (any thoughts?)
• Bumping the version in the source definition seems quite reasonable, particularly if we have different versions by library.
• We could attempt to publish to crates.io / PyPI / npm on every single merge, and allow them to fail if they're already created (though we'd need to parse the error message to ensure it didn't fail for another reason). At least for cargo, there doesn't seem to be a flag for "pass if it's already there".
  • Once pushed, a process could make the tags automatically (it needs to be that way around — we can't change the files based on pushing tags, since the tag would be attached to the old version)

Cadence

• We could do something like "nightly, assuming there's been a merge". Is there anything downstream that would be upset by that many releases? Maybe something with dependabot or a low latency, constantly filing PRs?
• The extreme would be "every merge"...

Any thoughts?