I am very sorry but going on like that is impossible

[neshume]

I have been with bevy for many years now. i always find myself chasing the next version , never get to stabilize the games , it always breaks , always takes time. I have given up trying. I am moving out of bevy and i will not use for my games any more. Maybe i am missing something but this kind of development is not the right way , even the basic core changes all the time , porting is hell it takes time , money and effort.. thank you but no. Unless you decide on a functioning core that will not change so rapidly colors , structures windows , base of the base , I'm done here.

[Jondolf]

There's a reason the Quick Start guide starts with a stability warning 🙂

The standard in larger game studios using other engines like Unity, Unreal Engine, etc. is to pick a version and stick with it for the development of a game, not to spend a ton of time and resources constantly porting to newer versions. The same can be done with Bevy; you don't have to update unless you want to. Though, of course, because it is still evolving so rapidly, each version often adds things that may be very useful for your project, and learning resources can get outdated, so there is incentive to update. Whereas with more mature engines, there are typically enough features that there is less need to use the latest version.

Personally my experience (~3-4 years, though primarily as a library author) with Bevy updates has been that migrations really aren't too bad, typically taking 20 minutes to a couple hours to get things to compile and work like normal, and maybe some more to adopt any new features or APIs. The most painful part of migrations is waiting on ecosystem crates to update, but that is a bit better nowadays with the RC process, and oftentimes you can also update smaller crates yourself, if needed. Also, if you rely on advanced rendering internals, those can break in hard-to-debug ways.

But yeah, it's totally reasonable to use something more mature and stable; like the Quick Start guide says, Bevy is still in fairly early stages of development (game engines are big), and things break and evolve often :) I would expect stabilization to happen gradually, with core parts like the ECS having fewer large breaking changes over time. But no engine is ever finished unless it is abandoned, even engines like Unity, Godot, and Unreal Engine still have breaking changes.

[trung1-dothanh]

Agree. Chasing Bevy version is very frustrating for a serious project. Bevy has been in "early stages of development" for five years and from time to time there are too many changes about ergonomics instead of adding new functions.
I think at the current state, Bevy is only suitable for hobby project.

[Magnitus-]

I must confess, I'm finding it hard myself.

If I was a Rust veteran and had taken the time to really dig into Bevy end-to-end before writing a single line of code (I didn't have the time), maybe it would be easier. As it was, I quickly iterated through a Rust book during my parental leave (I wanted to both work on a game and learn Rust), put something together in roughly 6 months, didn't touch it for about 10 months after I got back to work and coming back, I'm putting myself back into context and... it took some doing to migrate from 0.14.2 to 0.15.3 (I was hoping it might help fix a problem I had, it didn't...). The breaking changes in the UI really set me back (I use UI all over the place, my game is 2D, plus the more declarative UI rendering style really appealed to my web dev background).

Loading my save games also broke. There are no examples that I could find about saving and loading a scene (even though saving and loading is a basic feature found in most games) which is a shame, because I rely on them a lot to get unstuck. In the end, of all things, chatgpt bailed me out (as it turns out, I was erroneously assigning to a scene and that was fine in 0.14.x, but really, it is a dynamic scene and 0.15.x militantly refused to do the assignment, but gave me a somewhat nebulous unknown loader type error).

I must admit, I was really eyeing Godot here for a bit and considered byting the bullet and just porting my game to it, probably with the Rust extension (I don't feel like using GDScript, I want to use an existing general-purpose programming language).

At this point, everything works with 0.15.x (minus my bug I need to resolve) so I think I'll just ride with that and hope the engine doesn't have too many bugs at that version, because I need to progress with my project. If I encounter a show-stopping bug, I'll re-evaluate whether it is easier to switch to 0.16.x or just redo it in Godot and etcetera.

What I won't do is keep up with the updates. In my particular situation, that would be insanity. But otherwise, I'm personally liking the ECS API. That was new to me when I started the project and it has a certain elegance to it.

[E72UJ]

I've been using it, and I admit there are indeed migration issues. My business involves creating a visual novel engine, and I've been trying to adapt Bevy to better suit our needs. For me, the most difficult aspect is the inconsistent UI API, requiring multiple migrations and tests to ensure stability.
I believe the UI issues will be greatly improved once the BSN macros are stable.

[Froidoh]

Personally I no longer believe in BSN and especially Cart's work (sorry, this is a rant and also has some argumentum ad-hominem, it's not meant in a bad way. Cart is a good engineer, it's just how he works and what bevy needs doesn't align with my vision as a small time contributor and, more importantly, as a user since the first version released in 2020 (!))

It has been years (!) since a focus on a proper GUI has been announced. Years!

And it's not like this is a small hobby project entirely.
Granted, most devs are doing it in their spare time or are being paid by third party companies who use bevy in-house, but BSN is not. It's paid for by sponsors. At some point I was one.

At that point to me it's vaporware. Always just another release away.

Too much bikeshedding, too much "perfect is the enemy of good". Everyone has an opinion on how to name that variable or function. "Can we rename it?" "I think it should be named that way" And another month goes down the drain. Everyone feels super important. At that point it's 100% like it is in huge organizations when you talk about a complex feature and then show a small mockup and the only questions and discussion points are "Wait, is that Pink?" "No, it's actually..."

NOBODY (BUT YOU) CARES! THE USERS HAVE A PROBLEM, LET'S SOLVE IT! WE CAN GO FROM THERE!

It doesn't have to be perfect on the first iteration! But it's better to have SOMETHING than to have NOTHING (!). There, I said it!

Many areas of bevy are developing very fast. Some too fast maybe (rendering, needs a lot of cleanups, but it's going there!)
Many areas are of course "unresearched". Like proper, ergonomic integration of UI with ECS.

These are not easy problems. They take time.

But what I can't take anymore is that carrot on a stick. That yearly (!) blog-post telling us that BSN is here, when it never arrives!

It's just absolutely wrong for Cart to sit on such an important topic alone for so long and block everything. He has even acknowledged that in the past with Assets rework...

I am an older engineer. And I've come to the conclusion that perfect is the enemy of good. When I was younger, coming fresh from university, I was a perfectionist as well. Over the years and decades (lol) I became more of a pragmatist. An 80% solution is better than being forever stuck at 0%.

My problem with the work is, that although there are PRs, they are huge and never incremental. As a user one never sees the fruits... worse: They are not even in the main branch, so one could toggle them on with a feature flag or something (I know, for huge rework that's not easy. But it's doable. I've been in jobs where we did that for hundreds of thousands of lines of code, enabling them gradually because the business would suffer hard if something went wrong and we would all lose our jobs)

Sidenote, if not obvious: Writing this not with my main account as I am a (smalltime) contributor myself and I am not interested in any more drama.

(Well aware that this can be interpreted as ironic, as my post reeks of argumentum ad hominem... I am deeply sorry for that @cart , it's just venting and getting rid of the frustration and moving on with my life!)

[Magnitus-]

Honestly, the more I think about it, the harder it is for me to say that their current policy is wrong in absolute terms.

It's definitely not great for smaller part time projects like mine (or yours I will guess), but if you look at their funding structure, it is clearly dominated by fewer organizations with more means who are "all in". For them, given their resources, all but the most humongous of incompatibilities are probably a small bump on the road and their more ambitious projects are likely to make full use of many of the new features so for them a fast backwards-breaking development cycle might be great.

And if those larger donors is what keeps the project alive (a lot more than the silver donations of contributors like me) and the goal is to keep the development of an open-source game engine sustainable, then mission accomplished (although if those large donors ever drop out, ouch).

I look at the ECS architecture which appears to be geared towards performance at a larger scale, what seems to me like an emphasis towards advanced 3D features, their current funding skew and I'm thinking that maybe the project is geared more towards an AA sized audience (or at least a consummate gaming professional in it full time). It definitely seems that way to me now and perhaps that is the longer term plan too.

And maybe some other engines will always be a better fit for much smaller indie work, especially if it is part time, 2D or if you are a beginner in the game dev scene. Anyways, just an educated guess.

For my part, I'll say that if I knew then what I know now when I started my project, I would have probably picked another solution (for my situation, it was not the best call), but given that my choice, while less optimal, hasn't been atrocious so far (I'll say that for Bevy, it's been a relatively bug free experience and their ECS model with seperate systems to manage different parts of your game has a certain elegance to it), so I'll just focus on completing my project on a fixed version of Bevy rather than eat the overhead of learning and converting to another engine at this point.

If I start another project later or really hit a facepalm moment with this one, I'll re-assess then.

[cart]

First: I want to say that I do think I've misplayed BSN development in a number of ways. You aren't the only one that is frustrated (and that includes me!). I'm glad that you are voicing these concerns, and I'm sure many people feel the same way.

It has been years (!) since a focus on a proper GUI has been announced. Years!
Too much bikeshedding, too much "perfect is the enemy of good".
but BSN is not. It's paid for by sponsors. At some point I was one.

I do think I suffer from "perfectionist tendencies", and those were certainly a factor in the delays. But looking back over the last couple of years, I don't think those are the crux of the issue. I work full time, and I haven't just been endlessly tweaking BSN for all of that time.

I think what this really comes down to is that while my work on BSN is paid, that isn't the only thing I am paid to do. I'm paid to be Bevy's Project Lead, which means I'm ultimately responsible for and accountable for every technical decision in Bevy (obviously this doesn't mean I build or design everything myself ... far from it), in addition to spinning up and running the Bevy Foundation, community management, handling drama / disputes, release prep, marketing, being the voice of the organization, etc, etc.

When I think about where most of my time went over the last couple of years, a solid chunk of it had to be spent on non-development things, because it was "my job" to do those things. I wouldn't / couldn't change how I spent that time.

However when I consider the remaining time I could use for development, a significant portion of it went to vetting other peoples' designs or implementations, tweaking them, reworking them, etc. I think this is where the real "blunder" was on my part. I let whatever the community wanted to work on at the moment derail my own priorities.

This is a hard problem to navigate, and I consider it to be a bit of a "losing situation" no matter what I do. When a community member submits a PR that I consider to be a "potential liability" to Bevy's quality in one way or another (to the point that it should not be merged in its current form), I have the following choices:

1. Ignore it completely: This seriously burns contributor goodwill and leaves real value on the table. But it does allow me to focus on Bevy's highest priorities!
2. Don't stand in the way of it being merged: We are currently very understaffed (only two full-time, already very overburdened Foundation employees, very few active SMEs). This means that in practice, the quality issues often are not resolved (or even identified), and the quality of Bevy degrades over time. This ultimately burns user goodwill. I don't consider it to be a sustainable practice, nor am I interested in building mediocre, unvetted products.
3. Close the PR: Say "we aren't doing this right now", and go back to whatever Bevy's highest priority is. This burns goodwill and leaves value on the table.
4. Drop what I'm doing and fix it: This lets the work land well, keeps the contributor happy, and ensures we aren't wasting contributor effort, at the cost of making less progress on the project's highest priorities.

I've tried various distributions of these options over the years. Over the last couple of years, I've spent a lot of my time on (4). And given the volume of incoming work, if I choose (4) every time, I have no time left for other things. Building things to the level of quality I think Bevy deserves takes considerable time and attention. I'm easily burning days to weeks fixing or improving upon other peoples' designs and implementations. Even in the cases where they are already in solid, shippable condition, just establishing that they are can take days. In retrospect, I think I've let this derail what we all agree should be Bevy's priorities to an irresponsible degree.

It is my job to ensure the Bevy Organization as a whole delivers what the users need most. We are incredibly resource constrained from a developer perspective, and I've been letting the arbitrary whims of individual contributors dictate how those resources are spent. This needs to change. For awhile now I've been developing plans for 2026 that aim to refocus our efforts and provide some much needed structure, while still preserving the community's ability to build and explore areas outside of our top priorities. One of the main goals will be to build a trustable process that allows people in Bevy's design leadership roles (project leads and SMEs) to say "no" or "not now" earlier in the process. I emphasize trustable because currently, getting design leadership's attention early is hard (especially mine). The current system, coupled with my own behavior, encourages "build first and yell for attention". This is not optimal, and sets up the "losing situation" outlined above. I think the Working Group system has been a massive success. I attribute this (in part) to (1) pre-vetted / blessed directions, with an early commitment from leadership to help the projects succeed and (2) centralized planning that encourages collaborative design and global thinking. I'd like to apply those benefits more broadly.

NOBODY (BUT YOU) CARES! THE USERS HAVE A PROBLEM, LET'S SOLVE IT! WE CAN GO FROM THERE!

Preach! I know I've focused on other issues in this response, but I do agree that BSN could have landed faster with a more pragmatic "get it in peoples' hands asap" approach, and I think that would have served us all better.

Writing this not with my main account as I am a (smalltime) contributor myself and I am not interested in any more drama.
as my post reeks of argumentum ad hominem... I am deeply sorry for that @cart

No need to apologize. This type of feedback is valuable to me. It is my job to serve the community, and if I only ever hear positive feedback I'll never improve. I respect the desire for anonymity, but I also want you to know that I would not hold this feedback against you if you want to talk about it (either publicly or in DMs) from your main account. Anonymous is also good though! We really need an anonymous feedback form / suggestion box.

[alice-i-cecile]

We really need an anonymous feedback form / suggestion box.

This would also be useful for sensitive moderation reports too actually.