4 ms·

Have you considered moving off of 0.x.x? You have people consuming this software, it's public, and if you plan on breaking it quarterly, just be upfront with pe

Have you considered moving off of 0.x.x? You have people consuming this software, it's public, and if you plan on breaking it quarterly, just be upfront with people and move through major versions. LÖVE made the same mistake for years, and their version history looks odd as a result due to the sudden jump from 0.10 to 11.0. You'll be working on Bevy for years. When do you decide it's ready for public "stable" usage, and how do you plan on communicating this to users?

ncallaway 3y ago
> and if you plan on breaking it quarterly, just be upfront with people and move through major versions. 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.
- andrewmcwatters 3y ago
  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. Maintainers of all sorts of different projects also signal to their users their investment value in working with a large critical dependency.
  - CooCooCaCha 3y ago
    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.
  - unshavedyak 3y ago
    > 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?
  - ncallaway 3y ago
    > 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.
deleted 3y ago
[deleted]
alice-i-cecile 3y ago
We've discussed this pretty recently on GitHub [0]. I'm personally in favor of shipping 1.0 within the next year or so. The most interesting part of that to me is figuring out how to decouple the crates without creating major confusion, in order to reduce trivial plugin churn. For the most part, this is just marketing and semantics, but Bevy is nearly ready for commercial users and we should start communicating that. Quite a few brave users are already building production games (and non-games), and feedback is generally very good! [1] [0]: https://github.com/bevyengine/bevy/discussions/9789 https://github.com/bevyengine/bevy/discussions/9789 [1]: https://github.com/Vrixyz/bevy_awesome_prod https://github.com/Vrixyz/bevy_awesome_prod
- epage 3y ago
  I'm hoping public/private dependencies RFC will help some. One idea we have for a follow up is to declare that you should get the version req for one crate from another.
earthling8118 3y ago
It can be communicated when it becomes stable and goes to 1.0.0 for the version. Until then it shouldn't dare move past 0.x.0 just because people think it should.

ncallaway 3y ago

> and if you plan on breaking it quarterly, just be upfront with people and move through major versions. 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.

andrewmcwatters 3y ago
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. Maintainers of all sorts of different projects also signal to their users their investment value in working with a large critical dependency.
- CooCooCaCha 3y ago
  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.
- unshavedyak 3y ago
  > 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?
- ncallaway 3y ago
  > 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.

deleted 3y ago

[deleted]

alice-i-cecile 3y ago

We've discussed this pretty recently on GitHub [0]. I'm personally in favor of shipping 1.0 within the next year or so. The most interesting part of that to me is figuring out how to decouple the crates without creating major confusion, in order to reduce trivial plugin churn. For the most part, this is just marketing and semantics, but Bevy is nearly ready for commercial users and we should start communicating that. Quite a few brave users are already building production games (and non-games), and feedback is generally very good! [1] [0]: https://github.com/bevyengine/bevy/discussions/9789 https://github.com/bevyengine/bevy/discussions/9789 [1]: https://github.com/Vrixyz/bevy_awesome_prod https://github.com/Vrixyz/bevy_awesome_prod

epage 3y ago
I'm hoping public/private dependencies RFC will help some. One idea we have for a follow up is to declare that you should get the version req for one crate from another.

earthling8118 3y ago

It can be communicated when it becomes stable and goes to 1.0.0 for the version. Until then it shouldn't dare move past 0.x.0 just because people think it should.