> What will most likely happen is that there with be large subsets of Bevy users who never use a formally stable Bevy codebase, and then leave for something different, because there are no guarantees.

But naming it 1.0 won't give them guarantees either. If it's assumed, it would just be annoying when breakages do occur. What you're really asking for (it sounds like) is for there to be less breakages or longer term releases .. and that's a staffing issue imo.

If users avoid it because they don't want churn, and the devs are choosing churn - then everyone is in agreement currently, no? The bevy devs are writing software in a way that fits them currently, and users who prefer to wait for 1.0 are doing so currently. Everyone gets as advertised.

Do you see it working differently?

I think it depends on how the developer views 0.x releases. In Bevy's case there has been discussions around backwards compatibility and I think it'll happen but right now it doesn't make sense until the major systems are in place.

My impression from being in the community for awhile is that the devs don't want to perpetually stay with 0.x releases. It's just that a game engine is a big thing with a lot of moving parts.

> What will most likely happen is that there with be large subsets of Bevy users who never use a formally stable Bevy codebase, and then leave for something different, because there are no guarantees.

But you haven't asked for them to release a formally stable Bevy codebase. You just asked them to change to a 1.0 version that implicitly promises a stable codebase. You specifically asked:

"and if you plan on breaking it quarterly, just be upfront with people and move through major versions."

That's not being up-front with people. A game-engine that breaks quarterly absolutely isn't ready to be versioned with a major-version. As I said in response to your first post, a "0.x" versioning system *is* being up-front with people.

If instead of suggesting: "can you switch to a 1.0 major version that you increment quarterly", you're instead suggesting: "can you stabilize the API and not release breaking changes quarterly" I think those are two entirely different requests. Your first post made the former request, which is what I was responding to.