search

radashi-org / radashi

The modern, community-first TypeScript toolkit with all of the fast, readable, and minimal utility functions you need. Type-safe, dependency-free, tree-shakeable, fully tested.
https://radashi.js.org
MIT License
315 stars 25 forks source link

Release patches nightly #300

Closed aleclarson closed 3 weeks ago

aleclarson commented 3 weeks ago

During nightly publish-beta workflow, skip the beta release if only fix: commits exist and publish a patch instead.

aleclarson commented 3 weeks ago

Alternatively, publish patches immediately upon merging. 🤔

Another question is: what if an unreleased feat: commit exists in the main branch? The workflow could try rebasing without the feat commits, and if the rebase doesn't encounter merge conflicts, it can publish a patch.

MarlonPassos-git commented 3 weeks ago

I like the idea; in the current flow, we’re only handling major and minor releases, so this could be a way to introduce patch releases in between.

However, if we only use the main branch, this could lead to some issues.

Imagine someone adds a new function xyz, we merge it into main, which goes to @beta. Then, someone opens a PR with a fix for this new xyz function, addressing a type issue. Although this PR is labeled as a fix, it shouldn’t be merged immediately since it’s directly tied to a feat PR still in beta.

We could:

MarlonPassos-git commented 3 weeks ago

By the way, have you decided on the frequency for minor releases? Will it be monthly, every set period, or after a certain number of new features?

aleclarson commented 3 weeks ago

Here's how I've got it set up now (as of today):

  1. PRs with new features must edit next-minor.md
  2. PRs with breaking changes must edit next-major.md and target the next branch
  3. Those PRs won't be merged into main until the day they are officially released, but they can be labeled with prerelease to be copied into either the beta (for feature PRs) or next (for breaking changes) branch, which will be published immediately upon being pushed to, using either --tag beta or --tag next for NPM dist tag.
  4. Patches are merged into main, where they are published immediately.

Rebasing

Before a PR is copied into the beta or next branch, the branch is rebased onto main (i.e. it rebuilds itself on top of main). Note that main is not affected by this process. The rebasing is automatic (see the ./scripts/prerelease/src/prerelease.ts module).

If the rebase fails, the PR cannot be pre-released until the target branch is manually rebased.

Safety checks

Even if a PR is labeled with prerelease, it won't be pre-released until it:

  1. Passes all automated checks
  2. Gets approved by anyone in .github/CODEOWNERS file
  3. Is not marked as a draft PR
aleclarson commented 3 weeks ago

By the way, have you decided on the frequency for minor releases? Will it be monthly, every set period, or after a certain number of new features?

I hope to release minor versions once a month, but it's not a strict schedule. I think the automatic beta releases are a fine workaround here.

aleclarson commented 2 weeks ago

GitHub releases for patches are now automatically created 🎉

Same for pre-releases, but those are created in the radashi-canary repository.