Post

💥 just released a github action: `uppt` it aims to be a very simple, secure release workflow for maintainers that adheres to best security practices ⚪ trusted, staged publishing on npmjs.com ⚪ github environment protection ⚪ generated release PR + changelog ⚪ automatic release + publish on merge ✨

Curious, what are your views on changesets? I’m kinda torn

it looks really nice and I would consider it if I needed a more complex workflow or independent versioning of packages but I wanted something effortless + simpler, that works off of the metadata already present in conventional commits

I used to use changesets, but then helped develop release-plan -- which supports both same versions and independent versions dependening on config, and semver impact labels I do still miss the fidelity of a manual high context changelog entry tho

`uppt` supports editing the PR body so you can add context maybe a feature for release-plan?

Editing everything every step of the way if you want is supported - the release preview pr gives a last chance there But it doesn't use the pr description for changelog - i want a way for it to do so

But! How does uppt differentiate between info for changelog and info for reviewer ? (Why, how to review, considerations, etc) Seems very useful! I suppose it could be done with html comment markers or something

ahhhh no, I mean it supports editing the release PR body, which becomes the changelog entry. I find it _fascinating_ we both ended up with very, very close to the same workflow great minds, eh?

My conflict has been between fidelity, precision, and correcting for contextual breakdowns while not adding a bunch of extra overhead, especially for new contributors (especially especially for those new to development in general)

I wonder of there’s a way to bridge the gap like: By default a changeset is somehow autogenerated from the PR, but you could create or edit the changeset manually at any time (before or after the PR is merged)

I think the question is _when does the changeset generation happen _? Doing it on PR creation could lead to awkward “conflicts” for the contributor. Doing it just before merge means adding a manual step. Or could it be done on merge queue? Doing it on main means extra commits.

Doing it in the release PR means it’s harder to preview, but also you want to _remove_ the changesets in the release PR

yes, a big thing for me is avoiding manual tokens or github apps

Is the only option to not actually reify autogenerated changesets unless asked for? And then the release PR does that transparently. So in the PR merge you get a preview as a comment. At any point you can run a command to generate for a PR/commit.

If you want to edit when cutting a release, you have to commit a changeset to the branch you’re cutting the release from. And you need a way to write a changeset that says “skip this one you would autogenerate”. Or am I missing something?