Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Establish a Beta Release

See original GitHub issue

Having a beta release (or better said: prerelease) will let us incrementally produce a major (with breaking changes), better tested, more significant stable release. PRs tagged with breaking should be filed against the beta branch.

Issue Analytics

State:
Created a year ago
Comments:14 (9 by maintainers)

Top GitHub Comments

1reaction

nicojscommented, Apr 12, 2022

I’d be happy to test beta releases out in our StrykerJS e2e test suite. Especially if it saves us having to fix breaking issues for users later on 😅

Q: How will these beta releases be communicated?

1reaction

devoto13commented, Apr 8, 2022

@mtrea

will there also be a tax on contributors and maintainers once this is set up?

I don’t think contributors are affected in any way. Slight extra effort required from the maintainers to backport occasional fixes to another branch, but IMO that shouldn’t be significant.

Was there some incident that inspired filing this issue, or are you just being proactive?

We use semantic-release to automatically publish each merged PR as a new version. When merging breaking changes, it will automatically bump a major version. The primary problem we’re solving here is that we don’t want every breaking change to result in a new major release (which quickly gets out of control and results in noise and update friction), but instead have a way to batch several breaking changes into a single major release.

We would still use semantic-release to automatically publish each merged PR, but from the beta branch it would result in 6.0.0-beta.0, 6.0.0-beta-1, 6.0.0-beta.2 (and eventually 6.0.0 containing all previous changes) instead of 6.0.0, 7.0.0, 8.0.0, etc.

When you talk about “breaking changes”, do you mean our CI still passes but downstream users may be broken e.g. due to API migrations/etc? It seems you’re referring to intentionally breaking changes, which contrasts with unintentionally breaking changes which should be caught by CI.

Yes, it’s intential breaking changes. E.g. drop support for the obsolete Node version, remove deprecated or obsolete APIs, etc. As I understand these should not be breaking changes for Google as all usages should be cleaned up prior to landing the change, but for external user it goes other way around and we should communicate such changes with major version bump.