Revisit the release train model - make more stops along the track *choochoo*

[Froidoh]

Are you open to reconsider the release-train model?

First off: Sorry if this comes of rude, I am trying not to sound too entitled ;)

What problem do I face:

I know a lot of stuff is going on behind the scenes with bevy. There are so many new features being implemented, performance being improved, ergonomics being tackled, as well as certain very lacking areas (UI cough) being worked on but I, being a humble dev that can only spend a couple of hours per week working on my pet project, feel "left out".

What I mean by that: I tried following along main, but it turned out to be a nightmare. Every week I would just patch up dependencies and never make real progress on my game. So at some point I just gave up and selected dependencies that had versions for a specific bevy version.

Whenever a new version of bevy arrived (I am here since 0.4 btw!) I would eagerly port my game to it and be amazed by all the cool new stuff I could play with.

Now I don't know how hard it is to release, how much effort goes into it, but personally I prefer a fixed version (even if not completely stable) to the "let's just go with a random commit and see all the dependencies break" approach I have to do when following along main.

Personally I would love to have "dot" releases...

Like 0.10.1, 0.10,2, 0.10.3 ... finally resulting in 0.11 when the next "major milestone/release day" has come.

From my POV not every small release needs an entire huge blogpost (which I enjoy reading very much btw), but for me, as a bystander and someone actually trying to work on a game, it feels like a lot of velocity and momentum is always ahead, just never reachable. They also don't need to be super polished. Basically tagging a commit as a version and doing a release to crates.io every two weeks or so would be what I would love to see.

For library authors not much would change, I guess. Many are already following along bevy/main on their main branch, so they could opt in to release a new version of their plugins for a "bevy minor version" as well, or decide not to do it.

[james7132]

Even if we released a 0.10.1, we cannot include any breaking changes in it due to the requirements of adhering to semantic versioning. We'd need to cherrypick and backport every non-breaking change to make that happen.

If you find that following main is too much, and that can certainly be true with the increasing development velocity, the usual suggestion is to just use the public releases until the next release is available. Sans anything major, like stageless or the 0.6 renderer rework, the migration should still be relatively painless, and shouldn't consume all of the time at your disposal. If you absolutely must have the latest and greatest from main, go ahead, but it's your responsibility to keep it up to date.

We could change the cadence at which we're making releases, but IMO 3 months is a good intermediate. Rust's 6 week cadence is probably too short for us to get any major changes in, and it occurs just often enough that we're regularly delivering big feature sets. If this is to change, @cart should be the one to make that decision.

[Froidoh]

Even if we released a 0.10.1, we cannot include any breaking changes in it due to the requirements of adhering to semantic versioning.

Semantic versioning pre 1.0 means that the minor version is the major version, meaning that "0.10.2" is "semantically equivalent" to "10.2" in a sense that only "11.0" may introduce breaking changes.

Maybe we can release 0.11.0-pre0 and 0.11.0-pre1 or something like that? Axum did something like that.

[nicopap]

I'll just post a list of pros and cons:

• more releases means more work to plugin maintainers
• Plugin maintainers may decide to only update to full releases, but then aren't we back to status-co?
• End users may feel pressured into putting more work to sync to released version, which, as you testimony here, is exhausting.
• I agree that 3 times a year is a fairly long process (I'd honestly favor 4 releases per year) but I think this is what cart is the most comfortable with, and it's only 1 month additional wait.
• bevy in main may be broken or have temporarily stripped-down functionalities, making a release impossible. IMO I think bevy's trunk-based dev setup is really nice, and allowing minor releases would add a lot of frictions.

When passing to the train release setup, I recall some people suggested posting "blessed commits" that all plugin maintainers that follow main (but not too closely) could use as dependency for their main branch. Maybe it's worth considering? Posting a commit every 1 or 2 months in a dedicated github discussion thread seems like a descent option.

[Froidoh]

I recall some people suggested posting "blessed commits" that all plugin maintainers that follow main.

I would suggest to tag them then

[laundmo]

as a plugin maintainer with limited time, i already struggle to update to public releases in a timely manner. its highly unlikely i would update more often than that.

[mockersf]

Instead of 0.10.1, 0.10.2, and so on that forbids breaking changes, it would probably be 0.11.0-alpha-1, 0.11.0-alpha-2, ...

Bevy could publish those releases without any news and guarantees, but that would be giving visibility to something with no intent to patch potential security bugs. It's more work for a potential communication crisis. I don't think it's viable with the current people working full time on Bevy...

[Froidoh]

Hm, axum does something like that or at least did for 0.6 which introduced quite some breaking changes.