news: release 0.5.0

[cart]

This is a first draft of the 0.5.0 release blog post. Feel free to leave comments / suggest changes / help me fill in gaps I missed 😄

If something is missing, it probably wasn't intentional, theres just a lot to balance.

I'm posting this in draft mode because we're still missing the changelog and "whats next for bevy" section

[scottmcm]

Convenience RENDERED link.

[cart]

(I recommend viewing this with a local zola server to get proper formatting)

Just download zola and run zola serve

[alice-i-cecile]

Inconsistent capitalization of Run Criteria.

[alice-i-cecile]

Might be fun to mention just how long we can wait between runs to impress the magnitude of the reliability.

[cart]

Hmm i think the implied "it just works" is easier to convey and more approachable than something like "It is reliable up to a tick difference between last change and the last system run of 3 * u32::MAX/4 ticks, where each system run (and each frame) bumps the world tick by 1". While "true" and impressive, I think it muddles the message rather than driving it home.

[bjorn3]

2d_text.gif is rather large (3.79MB). Can you use an actual video format instead?

[inodentry]

@cart I have some pretty major criticisms about the current state of the blog post (discord discussion with other people, from that message onwards).

The Core ECS Rewrite from bevyengine/bevy#1525 is described in excessively verbose and unnecessary technical detail. It is currently somewhere between a third and half of all the content in the blog post. I agree that Bevy ECS is the most unique distinguishing feature of the Bevy project and should probably get the most attention, I just don't agree about this level of technical detail and rationale being appropriate for a release announcement post.

It also reads in a very different tone from the rest of it: everything else is covered briefly, with the user-facing aspects/changes showcased (which is a good style for a release announcement), while the stuff about the Core ECS Rewrite reads more like a technical post for ECS developers, full of jargon and implemetation details (much of the content feels similar to what was written/posted in the PRs themselves, for Bevy ECS devs). I don't think this is appropriate for a release announcement. I suspect a big part of the audience (who are not interested in ECS technicalities) would get tired/bored/overwhelmed quickly, part way through that giant section, and lose their attention span for everything else.

It doesn't help that most other new features are covered after that. I think it would be a good idea to rearrange the content, so that as many of the cool new things in the release as possible get visibility first, while readers have the best attention span, and save the Core ECS Rewrite for last. It is the longest section that is the hardest to read. You could split away the benchmarks graphs to showcase the perf improvements early near the beginning of the blog post, while saving the detailed explanation for the end.

Right now, the experience of reading the post feels very much like: come with a fresh attention span, "oh, PBR, awesome!", then get dragged into super technical detailed ECS implementation notes, gradually get tired and lose that attention span, and then skim through the rest of the long blog post (where literally everything else is!). This is very suboptimal and buries all the important user-facing features we have with the new release.

Also, much of the Core ECS content could really be slimmed down:

• The Archetype Graph: this is really an internal implementation detail, that most bevy users will never be faced with (other than the awesome performance it results in 😉 ). Currently, it alone, has a detailed section that is larger than many other sections, including everything in the blog post about PBR. It feels excessive and out of place.
• Ditto for "Merged Resources into World"
• and "Query Conflicts Use ComponentId Instead of ArchetypeComponentId" ... do we really need a detailed description of all the technicalities of how Bevy detects conflicting queries, in a Release Announcement?
• much of the bullet-point content under "Archetypes"

You could replace all of that with a link to the PR, for anyone interested in the details.

I don't suggest removing these sections altogether, just slimming them down. Briefly describe what the feature is and why it is important, but without too much technicality and implementation details. You could link to PRs or other sources of info for that.

Also, your explanations of the ECS are very "direct world access" centric, which feels out of touch with how most people use Bevy. You explain direct world access in extraordinary detail, with entire long sections about WorldCell and EntityRef/EntityMut, and only then show at the end, that "Commands have also been updated" to match it. Commands are the primary way that most users interact with Bevy ECS. I feel like that API should be given more prominence.

[inodentry]

Also, with the "Orthographic Camera" stuff, you forgot a very important aspect: it is now possible to use orthographic projection for 3D!

This enables people to make things like CAD applications, or "isometric" games that use a 3D orthographic view.

This is probably more important than the fact that you can select different window scaling modes/behavior.

EDIT: you could include a screenshot of the 3D orthographic example:

[stefee]

what is Duration? is this part of std or a bevy type? a link here to the docs would be nice!

[stefee]

I see it is part of std now - maybe just a small adjustment here for clarity

Suggested change

	Timers now internally use `Duration`s instead of using `f32` representations of seconds. This both increases precision and makes the api a bit nicer to look at.
	Timers now internally use `std::time::Duration`s instead of using `f32` representations of seconds. This both increases precision and makes the api a bit nicer to look at.

[bjorn3]

Maybe it could link to the official docs? https://doc.rust-lang.org/std/time/struct.Duration.html

[cart]

I'm planning on doing a pass that will make all of the "types" link to docs (like we've done in past blog posts). I'll do that here.

[mmdevcodes]

I may have missed it, but can you add what are the next steps and future plans are for Bevy?

[cart]

@bjorn3

2d_text.gif is rather large (3.79MB). Can you use an actual video format instead?

Good call. I got that from a PR / didn't record it myself so ill need to re-encode or re-record, but thats not too hard.

@jamadazi
Yeah those are good points. I'll slim some things down and rethink the order a bit. Thanks!

@mmahandev

I may have missed it, but can you add what are the next steps and future plans are for Bevy?

Yup those are missing. I called out that I'll be following up with those in the PR description.

[cart]

I just cut a good portion of the ECS rewrite content, with a general focus on cutting down on implementation details that make people's eye's glaze over.

I also moved a good chunk of content to the end, which lets us "move on" to other things faster.

I did leave a bit of the "blog post-ey" introduction to storage types as I think it helps set the stage / tells a solid story that justifies the work being done. People have responded well to this style in the past so I'm comfortable rolling with it here.

[cart]

Added a small "whats next" section at the end. Feel free to suggest items (but only if they already have people committed to working on them / plans have already been made)

[alice-i-cecile]

archetype invariants!

[alice-i-cecile]

Also Ratys's stageless work

[DJMcNab]

I believe in no more .system(). Maybe let's not promise it though

[inodentry]

@cart is there supposed to be a flight helmet picture that isn't showing? (near the beginning of the post, after the pbr balls)

The text suggests it, but I can't see one. (in the RENDERED link above)

[cart]

@jamadazi it won't show videos in the preview. You'll need to use zola to render the html. It is a webm encoding, which doesn't work in safari (yet). I'm planning on re-encoding before release.

[RoyAwesome]

An idea based on what @jamadazi said... perhaps you can salvage the deep technical details and write a "deep dive" blog post using them. I feel like that info is very valuable, but I agree that it's extremely verbose for a release announcement.

[cart]

Yeah good call. We could definitely do a blog post on the details.