-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release process #736
Comments
a couple of thoughts:
|
#795 allows us to use Next up:
I think it would be OK to have the same version across all crates — the other crates are mostly bindings for prql-compiler, and it reduces the dimensionality of the problem if everything is on the same version. Maybe there's be a time where there are changes to
This looks great, and allows for more oversight than Do you have direct experience with it @mklopets ? (I'll check it out more if not).
This does look good! IIRC https://github.com/argoproj/argo-workflows might have a way of enforcing this. I'm balancing two strong principles:
I worry a bit that "force push an amended commit please, in this format" is actually quite difficult. Can you think of ways where it's also easy? Including allowing things through with a warning if it's not exact? |
I think that in an ideal world, we'd be able to semantically version all packages, which means separate versioning for each. See my prev comment's last point. Not sure if this is actually doable for all packages, though (it would for prql-js).
Nope! For react-mapbox-gl, my biggest open source thing, version updates (it's only published on npm) were handled on a core contributor's machine, with them deciding whether to bump the patch, minor or major.
If people with push access agree to always squash-merge (this can be enforced via repo settings) and to always make the squashed commit message follow the conventional commits standard, it could work. Then, most contributors wouldn't need to strictly follow this (though CONTRIBUTING.md could ask them to). Not sure if this makes a lot of sense when squashing together e.g. 3 feat-s, 2 fixes and 1 chore, though. |
Good point — we can enforce on the PR title rather than the commit message. We may not need to have the merger responsible if there's a tool than can block a merge until the PR title is consistent. We currently enforce squash merging (and encourage breaking up PRs!) |
I've added an optional Conventional Commit check in #889 When orhun/git-cliff#100 is closed, we can try automating the Changelog. |
From #1350 (comment)
Possibly I'll try git-ciff now |
Not quite there unfortunately, ref orhun/git-cliff#132 |
https://github.com/googleapis/release-please is another option for automated changelogs. It has a really nice workflow where it keeps a PR open with a proposed changelog, and then doing a release is just merging that PR. It would do some of the work currently done by |
Also see this comment #1507 (comment) on #1507 .
|
This is mostly complete. I'll move the narrower automation question & todo to #2137 |
Now that some people are actually using PRQL, we should decide how to do releases.
Principles
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 ofprql-compiler
with zero changes. That would weigh more if we had something likedbt-prql
here, because it's more than just a binding forprql-compiler
.Automation
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?)Cadence
Any thoughts?
The text was updated successfully, but these errors were encountered: