The problem is that "the prototyping phase" isn't a real phase, and this doesn't specify if breaking changes will occur between major, minor, or patch versions. It gives developers no guidance of what semver to track based on their own willingness to endure breaking changes. Using a library that still can't tell you that is just asking for trouble.
> Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.
The 0.x is essentially used as way to tell people to use at their own risk since it isn't considered stable yet. Using a library like this isn't asking for trouble if you know what you are dealing with and in the context of bevy it currently means a breaking change every 3 months with a blog post and migration guide.
The entire Rust ecosystem works on a model of breaking changes for 0.x version happening in minor but not patch releases. In fact, I'm struggling to think of any software project that intentionally releases breaking changes in patch releases.
It's specifically not a question of knowing how the Rust community usually does these things, it's a question of "does this package conform to Rust's semver conventions, the official semver conventions, or something custom?"
The statement, _as its written in the docs_ implies "we do something custom." Whether that's true or not is irrelevant. I read it, interpreted it as a lack of governance or adherence to standards, and moved on. Any professional engineer would do the same.
Making a quick judgement based on an assumption that's provably wrong isn't really the definition of a professional engineer.
People can run anything they want however the fuck they want, I just won't use it. How's that?
> doesn't specify if breaking changes will occur between major, minor, or patch versions
What I'm telling you is that it _does_ specify that: by using a 0.x.y version they are explicitly specifying that breaking changes can occur between _any_ version. If you don't want to use Bevy because of that, then that's fine.
In Rust, 0.x.y would treat .y as NON-BREAKING, BACKWARDS-COMPATIBLE changes.
I don't think I'm stepping beyond the pale of reasonable engineering when I suggest that a package in the Rust ecosystem that doesn't follow the Rust semver guidance -- and doesn't EXPLICITLY STATE that they don't follow the Rust semver guidance -- is a library I won't touch.
The fact that there's so much confusion on this thread about what their semver policy actually is shows exactly why it should be stated upfront and not masked behind a generic "stability warning."
semver says that in 0.x.y, "anything goes." But that is just not true with Cargo.
This is also documented, emphasis mine:
> This guide uses the terms "major" and "minor" assuming this relates to a "1.0.0" release or later. Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.
While the semver spec has contained that line about 0.y.z, the semver spec also does not define ranges, that is, how specifying version requirements works. Cargo implements these things, like ^ and > and etc, the exact same way that every other semver implementation implements them.
That’s because very quickly the “use minor like major when major == 0” thing became the de facto way that people used semver in its earlier days. Implementations understood this, but the spec was never changed.
So Cargo does follow semver in practice, like everyone else. There’s a combination of discrepancy and under-specification in the spec; which is a great reminder that specifications tend to follow implementations, not the other way around.
It’s on my long list of things to do to eventually reconcile this in the semver specification, but it’s been a few years and I still haven’t managed it, so no promises there.
> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
It is also simultaneously the case that "anything may change at 0.x.y" is not true for Cargo. Cargo is stricter than "anything may change."
Maybe what you're saying is that Cargo is consistent with semver, but "just" stricter? I'd agree with that, absolutely. That is why I try hard to not say "Cargo doesn't follow semver." (Although it's easy to slip on that one.)
“Just stricter” is much more accurate than “doesn’t follow”, for sure.
“No semver implementation follows the major version zero sentence in the semver spec, and Cargo does what they all do” is maybe an even closer approximation. We’ll see how good I can do with more than 60 seconds rest between typing :)
- Don't put 0.0.x in prod ever.
- Probably don't put 0.1.x in prod, either.
- Maybe put 0.40.x in prod. Pin to 0.40 if you do.
- Put 1.x.x in prod, because they're basically done with it.
I get upset when these conventions aren't followed and I'm using something expecting them to be.
I did skip 0.7 since I remember upgrading from 0.6 to 0.8 directly, though.
The minor jumps are sometimes very small changes, sometimes giant ones (but alas, it's still a 0.x project, so I got not qualms)
You just assumed this, but this isn't true. Bevy uses semver like most of the rust ecosystem.
The warning is just telling people that the breaking changes will be frequent. It doesn't mean they will be in a patch release. I don't understand what's to be confused about here. Bevy never specified any custom release strategy because there isn't one, it's just semver like almost everything else in rust.
Real answer: Bevy is already very featureful, but we have a long way to go before we can start making "stable api guarantees". Locking things down right now would prevent us from achieving the best apis we can. We are building the engine in the open and people will naturally still take dependencies on us, even under these constraints. We are very careful about our messaging / provide warnings in the appropriate places.
In practice, migrating between versions is generally pretty straightforward and we provide migration guides to help the process. The dust is already settling on some of our APIs / they're starting to feel "stable". Many people (and companies) are happily building real products right now in Bevy (and porting them across versions).
I've been working on a project in Bevy for the last few weeks, having previously attempted it in TS+pixie.js and Godot. It's been a joy in comparison, with much faster progress - in TS I was constantly fighting the ecosystem, and GDScript is just awful, particularly it's type system. Thank you!
Glad you're enjoying Bevy so far!
We want to make a break from Unreal pixel streaming and Rust on the frontend delivered over WASM/WebGPU would be so ideal. The rest of our stack is Rust, so it would slot right in with our Rust monorepo.
[1] I was donating to one of the devs until GitHub removed PayPal payments without warning or mitigation about a week ago. I'll fix that soon.
Code-first is lovely, but being able to fine-tune things without a recompile is key, and the workflow needs to work for any artists on larger teams too.
How did you tackle the problem of components containing geometry for platform-specific graphics engines? Does Bevy use platform-specific components? If an application needs multiple offscreen textures to compose a frame, are there components that contain metadata for which passes they belong to (so, now, platform and pass specific components)?
1. We build on top of cross platform abstractions with feature detection (wgpu is our cross platform low level graphics library, cpal is that for audio, etc). We build our features in a way that adjust the ECS app logic according to what features are available at runtime 2. In a few cases we do "compile time feature/platform detection" to select the appropriate code for a given platform. But most "Bevy features" don't use this / we opt for (1) more than anything else
In the case of geometry: that has a "dynamic" representation that can be adjusted according to the platform context (although in practice we don't do any platform-specific geometry transforms yet). And that gets written to the platform's gpu using wgpu.
Bevy has a "render graph", which feeds on Bevy ECS data. We adapt the render graph (and the ECS data that drives it) according to the features supported on a given platform.
(not _yet_ my highest priority, but others are already investigating this)
I see in the Bevy FAQ that you've contributed to other open source game engines. How did you get originally interested in game engine development? Are you developing a game yourself using Bevy? Or contracting with any studios using Bevy in their games?
Currently I only build small jam-like games in Bevy (I participated in https://itch.io/jam/bevy-jam-1 and https://itch.io/jam/bevy-jam-2). But I plan on picking up a larger project soon. I've got the itch :)
Do I need to learn Rust first, or does Bevy use a limited subset of the language like Unity and C#. Although I'd argue till I'm blue in the face C# is a much easier language.
In simple game code you don't need to write your own traits, use unsafe, and like laundmo says, the borrow checker pains are way easier than in most Rust codebases because there's already a nice architecture in place.
I'll add, a ton of work seems to be happening in rendering. This is not an area I can contribute or know enough about, but I am able/willing to help with just about everything higher level than that.
I strongly suggest any of the docs issues, as it doesn't require you to write any actual functionality, but forces you to get to know the architecture, the language, and the core parts of the engine itself.
The only reason we haven't merged it yet is we need to sort out a high level "app api" thing: WebGPU requires async init (as in the Rust async feature). The PR above solves this by making our plugin init async. This is the most straightforward, but it makes people put `.await` in their app init, which we're not sure is the right call yet. We're discussing alternatives that might "encapsulate" the async.
How is Bevy going to approach this kind of render pipeline customization?
For a comparison with Unity, it's equivalent to the scriptable render pipeline, but abandoning the default one doesn't mean you need to write your own pipeline from the ground up.
And what's the equivalance of Unity's Frame Debugger? Since Bevy doesn't have a GUI editor yet, I guess the answer is just to use Render Doc?
The best 10,000ft view that doesn't just point you at the code itself is probably https://bevy-cheatbook.github.io/gpu/intro.html. If you need finer details, you'll need to read the code itself, or ask in the #rendering(-dev) channels on the Discord.
Again, I'm not happy with the state of public documentation for this, but as seen with this release, it's still heavily in flux. I don't think we've had a single release since 0.5 that hasn't made major architectural changes of some kind.
> And what's the equivalance of Unity's Frame Debugger? Since Bevy doesn't have a GUI editor yet, I guess the answer is just to use Render Doc?
Yep, just use RenderDoc right now. I don't think we'll have a good solution for this for a long while, since building one of those from the ground up is a huge undertaking.
Thank you very much for the answer!
The engine is very threaded in general. We do pipelined rendering so the next frame's logic is computed while the current frame is rendering, we multithread expensive potentially high-entity tasks like animation and transform propagation, all ECS systems run in parallel (which includes the renderer systems), etc. We'll use whatever cores you give us!
Additionally, while obviously not perfect, are you following new developments in AI based animation[0] and prediction based light transport[1]? Do you expect these types of automation to eventually become first class within Bevy, or any thoughts on how they can be best integrated into a Bevy game?
I'm one of the two developers currently behind our longer term animation efforts, and I am keeping up with the state of the art in terms of animation compression, streaming, composition, and generation, but there's still a sizable amount of groundwork and plumbing before any of that can even be attempted. We definitely need a lot more eyes on this area of the engine.
I'm curious how the dynamic nature of an Editor will interact with rust.