🚀 Use regular semver instead of prerelease tags on next releases

[Pike]

🔖 Feature description

Let's ship regular semvers for our next releases.

This should limit the number of packages we ship in each release. That should reduce the cognitive load on maintainers, and on adopters.

In my testing of a broken approach in the changesets project, this would mean that we'd ship some 90 packages instead of 200.

A possible downside would be that core plugins might jump by several release versions, worst case, they could jump from 2.23.3 to 5.0.0 (I think). That's if you do a breaking change in each next release.

I'd gladly take that, as version numbers are cheap.

🎤 Context

Right now, we're release everything under the sun on every release.

This is driven by the use of prerelease tags for the next releases, and some bugs on the changesets toolchain.

Effectively, this goes back to https://github.com/npm/node-semver?tab=readme-ov-file#prerelease-tags, which reads in backstage lingo: If we bump @backstage/core-plugin-api in a pre-release, we need to also ship a pre-release version of @backstage/plugin-todo, which references that core package with the specific pre-release version.

More details on why that also then affects the non-pre releases is in Emma's comment in changesets/changesets#382 (comment).

✌️ Possible Implementation

This would require the fixes from changesets/changesets#1291, and then we'd need to piece together some parts of the changesets tooling with custom tooling.

I'd not expect the changesets project to adopt a change like this, as it's a firm commitment on doing semver right in prereleases.

But the changesets toolchain is so modular, that the amount of code we'd need to maintain on the backstage side should be fairly minimal.

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

None

[Rugvip]

Hmm, seems kinda tricky to get this right with the proper NPM release tags as well as changelog communication. Could be something to explore though.

I think the need for this might be reduced a bit as we start to move over most plugins to a community plugins repo though?

[Pike]

For the implementation part, the whole changelogs code is a metric ton of packages, so I'm hoping that we can re-use a good amount of code. In principle, make the pre-release code work as is, but make the version bump pretend it's not a pre-release.

For the community plugins, I think the success of the community repo will largely depend on whether those plugins hold back adopters from updating core. I think this will depend on the actual inner workings of the repo, and its CI. Personally, I'd love to see CI testing community plugins on core pre-releases. That sounds like a decent compromise between catching some issues in the upcoming core release (either on plugin or core side), compared to running CI on each merge to master on upstream.

At which point that repo would benefit from proper semver in pre-releases, too.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Pike]

Still wanted on my side.

[Rugvip]

Added this to the new "Release Updates" milestone. Started collecting ideas for how we could improve our release process to potentially spend a bit of time on that in the future.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.