Maintainers of all sorts of different projects also signal to their users their investment value in working with a large critical dependency.
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?
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.
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.
Isn’t that exactly what a 0.x version means? This seems far more up front with people that releasing a 1.0 that bumps to 2.0 3 months later.
I think until the engine is baked enough that the API avoids breaking changes for years at a time it should remain pre 1.0.