Post

daniel r(ooooooh) in nyc 🇺🇸
@danielroe.dev

💥 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 ✨

daniel r(ooooooh) in nyc 🇺🇸
@danielroe.dev
NullVoxPopuli@nullvoxpopuli.com

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

0 reposts1 like

Wes
@notwes.bsky.social

This is exactly the kind of conversation that could bring the package maintenance working group back together lol. Pretty sure I even proposed that we build release tooling sometime a while ago.

naugtur
@naugtur.pl

If this is not the right moment to do it, I don't know what is. Let's reach out to OpenJSF to reboot and start getting organized

NullVoxPopuli
@nullvoxpopuli.com

I used to build release tooling, and then I went through: release-it (didn't like tag-based automation) then semantic-release (didn't like commit strictness) then changesets (I like the changelog fidelity at review time, but it fell apart trying to get others on board, and distracted submitters)

Wes
@notwes.bsky.social

Since then I have built two of these type of pipelines for work, tried to translate some of that into a project, but didn’t have time to open source it, and helped some teammates roll out our final version of this just recently at work.