Lets Discuss (Eventual) Bevy Stabilization / Bevy 1.0

[cart]

First: I don't think we're ready for any form of stabilization yet. This will be a long path. Just trying to start the conversation while we have plenty of time to let it simmer.

I think we're still at least a year or two away from a Bevy 1.0.

What does stabilization accomplish?

Stabilization accomplishes a number of goals:

1. It implies that breaking changes will be rarer. This is actually a complicated (and unsolved) topic for Bevy. If we release Bevy 1.0, that means that Bevy 1.1 must be non breaking. If we were to do a Bevy 0.X-style "break whatever you want" release like we currently do, that would require a Bevy 2.0 release. Do we continue doing "major version" releases every X months (currently 3)? Or do we do minor version releases every X months and then major version releases every X*Y months? Lots of open questions here.
2. It signals to the world that Bevy is "ready" for adoption. It is a promise that we have complete workflows that we believe professional developers should adopt. It serves as a rallying cry for the wider gamedev community to start taking us seriously.
3. It (ideally) means we have a stable platform for Bevy Plugin developers to build on. By the time we are "1.0", plugin developers should not have the "break every 3 months" churn that they have today.

How (1), (2), and (3) should work is very TBD. We can discuss that here (I'm leaving this discussion open ended).

However I have one thought that I'd like to discuss earlier rather than later:

Partial Stabilization via some bevy_platform crate

Maybe we don't need to wait for the whole engine to be stable before we start stabilizing. Before a "true Bevy 1.0" (and whatever release scheme comes after), we could start building a "stable" bevy_platform meta-crate.

It would be structured like the bevy meta-crate, but it would only contain "core" pieces of functionality unlikely to change.

An initial bevy_platform = 1.0 crate would likely contain something like bevy_ecs, bevy_app, bevy_util, bevy_core, bevy_reflect, and bevy_time. Stuff that we will eventually (and ideally sooner rather than later) stop breaking regularly. And also stuff that provides a minimal foundation that some plugins could build functionality on.

We would continue releasing Bevy 0.X releases normally. But a given Bevy 0.X release would internally depend on a specific bevy_platform version (and re-export the bevy_platform::x crates as bevy::x ... for example bevy_platform::ecs to bevy::ecs).

A subset of Bevy Plugin authors could then enjoy longer stability windows (and not break across bevy crate revisions) provided they limit themselves the the bevy_platform crate.

To justify bevy_platform's existence we would probably want a first release to support a reasonable chunk of existing plugins.

Some plugins might be able to do "baseline bevy_platform functionality with optional bevy features". Ex:

[dependencies]
bevy_platform = 1.0
bevy = { version = "0.13, optional = true }

This would be a path for something like the bevy_rapier3d crate to provide "baseline" bevy_platform functionality with opt-in bevy functionality (for things like debug rendering). That way when we release the next bevy version, provided it also relies on bevy_platform = 1.0, users don't need to wait for bevy_rapier3d to update to the new bevy version (they just need to wait for the opt-in debug visualization features to be updated).

We would still likely need to break the bevy_platform crate on occasion. By the time a Bevy 1.0 happens, we'd probably be on bevy_platform = 3.0 or something.

Over time as things stabilize, we would pull more and more things into bevy_platform (ex: bevy_render would likely take a good chunk of time to be added, as it is still heavily in flux). Eventually we could merge bevy_platform into bevy and bump to 1.0 (aka do the Bevy 1.0 release).

The "stability" (how often we release a new major version) and functionality of bevy_platform would also be a very good "are we ready for Bevy 1.0 yet?" measure.

[alice-i-cecile]

One of the things that "1.0 stability" would mean to me is backported bug fixes to pre-announced Long-Term-Stable releases. That means a team can target a single stable version to make an entire game with, and expect that non-breaking fixes will actually reach them.

That works well with Rust's semver conventions: we ship 1.0, then X months later ship 2.0 and so on, but continue to release 1.1, 1.2 etc for a couple of years with the fixes we can manage.

[james7132]

Unity and Unreal have yearly release cadences, and have 2 years of support after the fact. Note that while this is a major development time sink long term, it does not necessitate the same level of customer support that proprietary game engines provide: this is strictly the effort needed to review and merge bugfixes and potential backport important non-breaking changes to older versions.

I am for a potential 2 year support period for development at the very minimum. Anything that is actually a 4+ year LTS is going to need significantly more effort than what an open source project can handle by itself, and will likely require actual paid support of some kind.

[alice-i-cecile]

On release cadence: I think that a 3, 6 or 12 month breaking changes release cadence is all defensible. Like before, we would still very much want to do train releases. I think Godot 4 adequately demonstrates the danger of not doing so.

[Nilirad]

I think that, for organizational reasons, a 12-month major release cadence is best.
The main reason is that we can pinpoint a specific time of the year to release. This could have the benefit to have a very precise release period, given that we choose a day where most people are willing to contribute to the finalization of the release (i.e. they are not busy with vacation, exams, etc.)

[james7132]

Beside the fact that 3 month cadence is basically the current status quo, I'd like to put my vote towards a 12 month breaking release cadence, which should give us more time to cook on big breaking changes and provided the community a guarantee that there won't be significant feature churn over the course of a short game dev cycle (1-2 years).

[alice-i-cecile]

On bevy_platform: reasonable idea. Our various crates are at very different levels of stability, and that will only be more true in the future.

I'm a bit nervous about figuring out releases and tracking this, given how manual and time-consuming our releases are currently.

On the current status of the crates listed:

• bevy_app needs some genuine improvements and re-architecting (plugins, subapps, !Send data) before it's something I would be comfortable stabilizing.
• bevy_ecs will continue to have shiny new features periodically (relations!), but the rate of "small breaking API fixes" is slowing.
• bevy_utils is basically ready today.
• bevy_reflect still seems to have some architectural churn to resolve.
• bevy_time: needs Unify FixedTime and Time while fixing several problems #8964 and maybe some love for time-stamped inputs, but once that's done we're good to go.

Other crates:

• bevy_input: slow-changing, but likely to need some rearchitecting
• bevy_log, bevy_math, bevy_gilrs, bevy_ptr: ship it: these are basically stable
• bevy_core: should be scattered to the winds TBH

[mockersf]

An even more reduced version of bevy_platform is bevy_types. With this, there's little guarantee on behaviour stability, but only on ... types. We could move a lot of the basic types defined by Bevy in that, and plugins depending on them won't break on a new release.

With even more granularity (bevy_ecs_types, bevy_pbr_types, ...) this would mean a change in PBR won't impact plugins that only uses the ECS, but at the cost of more crates to maintain.

An example of that is the geo ecosystem:

• https://crates.io/crates/geo-types has the primitives types
• https://crates.io/crates/geo has the algorithms

as their doc says:

The geo-types library defines geometric types for the GeoRust ecosystem.

In most cases, you will only need to use this crate if you’re a crate author and want
compatibility with other GeoRust crates. Otherwise, the geo
crate re-exports these types and additionally provides geospatial algorithms.

[soqb]

i wonder how much we would want to hold off on stabilisation or work with rust-lang/rust while we wait for Rust language/stdlib features that we would like to adapt to (e.g. const TypeId)

[Andrewp2]

I think as a first step it would be useful to add a milestone for "Bevy 1.0". #254 and #85 seem like they can be added to the 1.0 milestone immediately.

[soqb]

annoyingly, there's a lot of work for stabilisation that's largely out of our control. cargo's particular flavour of semver means we can't have exports from non-1.0 dependencies (e.g. glam). we'd need to push hard for stabilisation in these crates, wrap the relevant apis in our own thin layer or annoyingly violate semver in certain cases (perhaps only with the assent of the respective crate developers).

[rlidwka]

cargo's particular flavour of semver means we can't have exports from non-1.0 dependencies

Why not?

If I remember correctly, semver 1.X works exactly the same as semver 0.1.X.

[JoJoJet]

A fairly major thing we'll want to decide on before stabilizing bevy_ecs is how we handle commands. If we end up doing command batching to reduce archetype moves, we will likely want to remove support for System::apply_deferred and force all deferred mutations to go through Commands.

[andyy-garcia]

I am new to this engine and I'm not professionnal game dev so maybe my comment is not relevant, or maybe this is just not the right topic to point out those things, but I think that the first two things that I would consider when looking for adoption are :

• Is the engine code-oriented or asset oriented ?
• Does the engine make it easy to define and make plugins, and import and control their effect (sandboxing/composing) in our projects without too much pain ?

I emit the first criteria because it seems there is enough serious engines being asset-oriented, where you are expected to download an editor and start from it, where the game code is somewhat an "extension" of the engine constructs and assets rather than the starting point of the application. It's nice and fancy for artists or newbies wanting to try out game-making, but finally, the kernel of a real game is always the code. The dev team is the team which links all things together. Some developers may appreciate that the game starts in a humble main() function. This feels more programmer-friendly. It feels easy to customize engine bootstrapping and select the runtime features. It's nice that Bevy is made this way while striving to become a feature-complete engine.

But for programmer-friendliness the second criteria may also matter a lot and I think it's important to make it fulfilled for a 1.0 release. If the engine is thought as a platform rather than just a simple library to make 2d/3d renderings, then the engine must make it easy for an ecosystem of reusable features to be built and used, with parallelism and safety in mind. For Bevy this implies that the plugin architecture be taken seriously since this is the junction point between app developers and middleware developers. At this time in Bevy a plugin seems to be at the core a simple function that registers Systems in the app that invokes the plugin, but I see no way for the host developer to import a plugin with a fine-grained control over it, for example, overriding their way of reading/writing world's data (components/entities) to ensure proper isolation, when needed, and also safety. If a plugin is written too naively and, either in general case, or either in the specific context of an app, wrongfully interacts with components or entities that the host app must keep intact in some game phase/state, then the developer must jump into the plugin's code to handle the problem and change things there (unless I missed a specific, non-hacky technique to avoid this ?). This may hurt the purpose of plugins. Would it be planned for 1.0 to make plugins virtualizable, less side-effect prone, through specific engine API ? I pointed out this concern in #9732 for a specific case I encountered but I hope a composable plugin architecture is considered generally as a serious thing.

[nerdachse]

so maybe my comment is not relevant

No, worries, it is :)

[HarveyUmbra]

Sorry in advance, I am not a native speaker and use a translator.

first question

If you have a Bevy 1.0 in the future, how do you want to deal with new better ideas.
You could use the current Bevy UI as an example.
Maybe someone has an idea that is Simpler, Faster and better than the old version.
How should one handle this fall?

Second question

How should one deal with "unnecessary" features.
An example of what I mean would be Blender.
Blender had a game engine integrated in the past, it was removed.
I believe the engine still exists as a plugin for Blender.

What I want to get at, when do you check the existence permission of a feature, how do you check feature and when do you remove features you don't want anymore?

[alice-i-cecile]

So, this is part of the process of breaking changes: these can only occur across a major version bump.

That said, I think Bevy has a very powerful tool that other engines / software simply don't: it's MIT license and extremely powerful modularity.

Suppose we want to drop bevy_ui, in favor of bevy_ui2, which takes a completely different approach. Once we're ready to remove it, the community who wants to continue with that approach can continue entirely independently off a community-maintained approach.

The only privileged modules are bevy_ecs and bevy_app: everything else could be written entirely by end users. We can do huge rewrites, and drop whole features, knowing that legacy users who want to keep compatibility with this can do so safely externally by simply forking the plugins and making the simple changes needed to keep up with our core ECS/App API.

[mrgzi]

Fırst: I am not much experienced about open source versioning but somethings came to my mind and I want to share with you.

I think this is depends on what we are aim for;

• Are we aim that to increase popularity of Bevy and community will grow?
• Will this project be aim for profit in the future? (Maybe you may want some companies to sponsor the project, but in this case, yes, the companies will want a stable version.)
• Is releasing version 1.0 will worth slowing down project development?

For me it doesn't matter if the project version is 1.0 or not because I am an indie game developer. I will always adapt my project for new breaking changes.

So my question is can't we continue without stable release?

[nicopap]

One thing that jumps to mind are breaking changes along the lines of: "changed a query parameter in a public bevy system". Which are theoretically breaking, but most likely doesn't affect anyone.

I'm not sure how you'd go about that.

It's probably worthwhile to have a wrapper type for systems that just wraps systems so that arguments are private, so that we can make them public.

[JoJoJet]

Many of these public systems should be made private, with a public SystemSet exposed to allow ordering. For systems that we want users to be able to add to a schedule manually, we should be able to add functions that return a SystemConfig{s} instance.

[94zhudaxing]

1.What problems does it solve with other engines?2.How to use most established game library( like physx)?

[lee-orr]

I'm curious about whether we actually need a stable or even crate-matching version of Bevy as a whole, as opposed to stabilizing individual sub-crates as the time comes?

Unlike most of the popular engines I know of, Bevy is build as modular to the core. That allows it a much larger degree of flexibility in versioning that with most other engines when it comes to things like versioning. Especially since, in practice, the "bevy" crate is nothing more than a container of known-to-work-together versions of the sub-crates. The closest comparison to other engines I can think of is Unity's package manager - which has a wide variety of unity features at different versions and degrees of stability, but unlike Bevy those features are much higher level rather than being part of the core functionality.

As far as I can tell, the big benefits of having a stable release & version are:

• being able to have publicity pushes around each release
• having a known-to-work-together set of dependencies you can count on in a prolonged development cycle
• reducing the need to adapt plugins/assets constantly

And I think those can still be achieved without needing to separate out a "bevy_platform", or even without having fully-stable versions of all the sub-crates. Essentially what we'd need are multiple "meta-crates" (i.e. crates that collect the sub-crates at a specific version, like the bevy crate does right now) with different dependency lists based on their stability. A release of a stable bevy version, or an LTS bevy version, would basically amount to issuing an update to a "bevy_lts" or" bevy_stable" crate's dependencies, and then for each of those dependencies we can follow best practices for back porting non-breaking fixes as needed.

One last important aspect here is that they don't need to be actually separate crates - they could just be different versions of the bevy crate. It's more about the recognition that the main function of a stable "bevy" is to aggregate versions of it's sub crates that are known to work together, and not update their versions to breaking versions during the lifecycle of that stable release.

[NatanAmorim]

I am new to this engine and I'm also not a professional game dev so maybe my comment is not relevant, I want to get my 2 cents in and hopefully is something useful, I'm also new to rust and planning to use bevy in the future when it's stable.

If you have a Bevy 1.0 in the future, how do you want to deal with new better ideas.
You could use the current Bevy UI as an example.
Maybe someone has an idea that is Simpler, Faster and better than the old version.
How should one handle this fall?

I really like how Flutter does it so far, Flutter has 3 branches "Main", "Dev" and "Stable", the stable versions come at random intervals and even many versions later, like the last stable version was "3.24.5" and the next stable is "3.27.0".

The part I like the most is when something is done in a better way then the old way, what they do is put an annotation "@deprecated" and a description of which new thing substituted the old one (sometimes with a link for more details), this is also very integrated with the LSP, the deprecated code is highlighted and it will also make suggestions on how to auto-convert to the new thing if possible. The deprecated code is eventually removed from the code about a year later.

[alice-i-cecile]

Rust has the #[deprecated] annotation and it's great! Bevy uses it quite a bit, although not everywhere. I push for it more on high impact changes, or ones where a quick skim of the docs won't find a rename.

[viridia]

The big problem I see with any stabilization effort is the inability to enforce the policy. Bevy relies almost entirely on volunteers: we have no way to force them to do anything, and people working for free tend to be most interested in working on the new and the shiny. It's hard to find dedicated people who will do grunt work for free. While we can refuse to merge PRs that don't follow the policy, this requires taking a hard stance, and the resolve to hold the line can easily falter in a storm of passionate arguments.