Closed max-sixty closed 1 year ago
a couple of thoughts:
@types/...
TypeScript type packages are versionedreact
releases v18.1.0
, @types/react
would also release v18.1.0
, but can then independently improve things in @types/react/v18.1.1
without the underlying react
packages changing; react@v18.2.0
would then again come with an updated @types/react
packageprql-wasm
npm package would always match the corresponding prql-compiler
's version, but prql-js
would just be a peer dependency of prql-wasm
, and could independently have major version bumps (e.g. when the API changes to throw errors instead of return them under result.error
)https://github.com/prql/prql/pull/795 allows us to use cargo release
, which I used manually the first time. The release workflow does the releases to PyPI & npm.
Next up:
what if the minor version matched between all packages, but patches wouldn't need to?
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 prql-java
but not the other crates, but I think that'll be quite rare. If it does happen, I think the suggestion of allowing patch numbers to advance at different speeds sounds great. cargo release
seems to allow for this, but I'd be impressed if it handles the cross-dependencies.
there's something called Release Please for automation on top of conventional commits
This looks great, and allows for more oversight than cargo release
seems to.
Do you have direct experience with it @mklopets ? (I'll check it out more if not).
I quite like using conventional commits for commit messages in any case
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 it would be OK to have the same version across all crates
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).
Do you have direct experience with it @mklopets ? (I'll check it out more if not).
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.
I worry a bit that "force push an amended commit please, in this format" is actually quite difficult.
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.
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 https://github.com/prql/prql/pull/889
When https://github.com/orhun/git-cliff/issues/100 is closed, we can try automating the Changelog.
From https://github.com/PRQL/prql/pull/1350#discussion_r1057892244
If anyone knows a good way of generating changelogs with both a PR reference and the contributor, that would be v useful — anything we can do to raise the status of contributors is great (even though this time it's mostly @aljazerzen...).
(but without adding a burden on contributors themselves, e.g.
changie
)
Possibly I'll try git-ciff now
Possibly I'll try git-ciff now
Not quite there unfortunately, ref https://github.com/orhun/git-cliff/issues/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 cargo-release
, a tool which I'm very happy with and would be keen to retain.
Also see this comment https://github.com/PRQL/prql/issues/1507#issuecomment-1399576956 on #1507 .
Update from the meeting:
- introduce stable branch which tracks the latest release + hotfixes/tweaks + docs changes,
- most PRs are still merged into main (including docs of new features),
- book & playground are released from stable branch,
We can look into having another release for the main branch published in parallel to current deployment, so there would be a "bleeding edge" for people to experiment with. For now, we can try to keep releases frequent.
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?