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

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.

this was my original implementation ... then later added the 'auto-release' functionality

Automation is so nice! The thing i'm excited for next is plugins: with a way for them to all be idempotent like the existing bits: github.com/release-plan... Reason: i want to have vscode marketplace and open vsix plugins in addition to npm cc @evoactivity.bsky.social <3

I have very similar plugin plans for bumpy.varlock.dev 🐸 I think it fixes some things you were wanting in changesets. I’m fairly convinced that a file based workflow is right for non trivial cases. Also bumpy has a command to generate a bump file from conventional commits - best of both worlds.

I do wish we could merge codebases so both efforts can live on and everyone gets credit <3