diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index b5cd3f22ef..2ecc460f38 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -108,8 +108,9 @@ jobs: key: assets-${{ steps.date.outputs.date }}-${{ hashFiles('generate-assets/**/*.rs', 'generate-assets/Cargo.toml', 'generate-assets/generate_assets.sh') }} - name: "Build Bevy Assets" - # Only run if in merge queue or if no cache was found - if: ${{ github.event_name == 'merge_group' || !steps.restore-cached-assets.outputs.cache-hit }} + # Only run if in merge queue or if no cache was found. `cache-hit` is a string, so we + # cannot use normal boolean operators on it, as `!'false' == true`. + if: ${{ github.event_name == 'merge_group' || steps.restore-cached-assets.outputs.cache-hit != 'true' }} working-directory: generate-assets env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} @@ -245,7 +246,7 @@ jobs: path: content/community/people - name: "Build website" - uses: shalzz/zola-deploy-action@v0.18.0 + uses: shalzz/zola-deploy-action@v0.19.2 env: PAGES_BRANCH: gh-pages BUILD_DIR: . diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml index 58e909a97f..09e02743b4 100644 --- a/.github/workflows/deploy.yml +++ b/.github/workflows/deploy.yml @@ -46,7 +46,7 @@ jobs: - name: "Build and deploy website" if: github.repository_owner == 'bevyengine' - uses: shalzz/zola-deploy-action@v0.18.0 + uses: shalzz/zola-deploy-action@v0.19.2 env: PAGES_BRANCH: gh-pages BUILD_DIR: . diff --git a/.github/workflows/update-screenshots.yml b/.github/workflows/update-screenshots.yml index c556df83ff..b6c40b3dde 100644 --- a/.github/workflows/update-screenshots.yml +++ b/.github/workflows/update-screenshots.yml @@ -3,6 +3,9 @@ name: Update Screenshots on: workflow_dispatch: +permissions: + pull-requests: write + env: PER_PAGE: 20 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 399a0051f5..38e5cfc984 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,199 +1,5 @@ # Contributing -So, you want to help with [Bevy Website](https://bevyengine.org/)? Then this is the right place for you! Bevy is created by volunteers; if you want to help us build the next great game engine, please reach out. We need all the help we can get. +We've moved our contributing documentation! -If you want to help with [Bevy Engine](https://github.com/bevyengine/bevy) itself, then see the engine's [CONTRIBUTING.md](https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md). - -We want Bevy to be a vibrant developer community. That's actually why we chose the name; a Bevy is a group of birds, just like we are a group of game developers. Join the Bevy! - -## Building the website - -The Bevy website is built using the Zola static site engine. In our experience, it is fast, flexible, and straightforward to use. - -To check out any local changes you've made: - -1. [Download Zola v0.18.0](https://www.getzola.org/). -2. Clone the Bevy Website git repo and enter that directory: - 1. `git clone https://github.com/bevyengine/bevy-website.git` - 2. `cd bevy-website` -3. Start the Zola server with `zola serve`. - -A local server should start and you should be able to access a local version of the website from there. - -## Testing changes to learning material code examples - -The code in the learning materials (e.g., Bevy Book, Quick Start Guide, Advanced Examples, etc.) is compiled, formatted, and tested to make sure that the examples work for readers. - -To validate your code snippets either run `validate_examples.sh` which resides in the `learning-code-examples` directory (and is the recommended way to use `learning-code-examples`), or from the root of the project run `cd learning-code-examples && cargo check --examples && cargo clippy --examples && cargo fmt --check`. - -> [!NOTE] -> [See the `learning-code-examples` README.md for more info.](./learning-code-examples/README.md) - -## Learning material structure - -As you probably noticed, our introductory learning material is split into two main sections: - -1. **Bevy Quick Start:** "Get started making your first game now!" -2. **Bevy Book:** "Understand how Bevy works, and how you can use it" - -This is intended to cater to two different types of learners, without compromising the experience for either: - -- **Example-first:** These users want to dive right in, see everything in action and get a working game as quickly as possible. -These users often have an idea in their mind that they want to start prototyping as quickly as possible. -- **Definition-first:** These users want to carefully build up a mental model of Bevy, thoroughly understanding each new concept before moving on. -These users tend to be driven by curiosity, or are aiming to carefully develop a new skill. - -Crucially, these paths are independent of the experience levels of the learner! -Bevy intentionally aims to be inclusive of both complete beginners who have never programmed before, and professionals coming from other engines. - -| | **Beginner** | **Professional** | -| -------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------- | -| **Example-first** | Enthusiastic, wants to create a new version of the game they love. | Exploratory, wants to dive in and see how Bevy holds up in practice. | -| **Definition-first** | Curious, wants to understand how making games works. | Critical, wants to understand Bevy's unique design choices. | - -Each of these requires their own complementary learning paths that branch as soon as they get to the [Learn page](https://bevyengine.org/learn/) to ensure that the first experience that they have with Bevy matches what they need. - -Once users have completed the introductory learning materials in their path of choice, they can begin creating their own games or move on to our advanced examples to see how everything comes together in a realistic way. - -### Bevy Quick Start: the example-first path - -Users following the example-first path will tend to take the following route: - -1. Encounter the Bevy homepage due to social media or word of mouth. -2. Navigate to the Learn page. -3. Choose one of the most relevant **quick start games**. -4. Complete that tutorial. -5. Dive into making the game they have in mind, accessing the following resources as needed when they encounter road-blocks: - 1. Official Examples. - 2. The Bevy book. - 3. Community tutorials and template games. - 4. Various community support forums. - 5. Streams, YouTube channels and blogs. - 6. Advanced examples. - -Each quick start game should: - -1. Assume zero existing knowledge of Bevy. -2. Begin with a initial high-level explanation of what we're trying to build. -3. Introduce commented code first, then explain what each of the critical terms means as they come up. -4. Be broken into compilable, playable sections: one per page of the guide. -5. Gradually refactor the code to add more functionality. -6. End with a list of suggestions (with appropriate links) on how you could extend the game in interesting ways. - -This path should prioritize: - -1. Rapid time-to-fun. -2. Functional, good-enough explanations that are tied to the code in front of them. -3. Relevance of quick-start game to the genre of game they want to make. -4. High asset quality. -5. Ease of extending the quick-start game with their own tweaks. -6. Explaining how to get unstuck, through documentation, community help and filing issues. - -### The Bevy Book: the definition-first path - -Users following the definition-first path will tend to take the following route: - -1. Encounter the Bevy homepage due to social media or word of mouth. -2. Navigate to the Learn page. -3. Select the **Bevy book**. -4. Read through the book, largely in order. -5. Once they feel they have a good enough understanding of the engine, they will begin to make their own games, typically by jumping over onto the example-first path. -6. As they explore, they will also browse: - 1. The source code. - 2. [docs.rs](https://docs.rs/bevy/) - 3. CONTRIBUTING.md, GitHub issues and pull requests. - 4. Release notes. - 5. The engine development channels on Discord. - 6. Advanced examples to see how everything comes together. - -Each chapter of the Bevy Book should: - -1. Have a clear topic, and give a high-level overview of the subtopics it is going to cover and how they fit together. -2. Be broken down into several sections / pages to focus on detailed topics. - 1. These should have simple, minimal examples explaining how that functionality works. -3. Link to appropriate sections of quick start guides that demonstrate the ideas being taught in a more coherent way. - -This path should prioritize: - -1. Clear, thorough explanations. -2. Carefully introducing one concept at a time in an organized fashion. -3. Connecting concepts to each other in context. -4. Explaining the technical details of how things work, but only in clearly marked asides. -5. Communicating all of the supporting development practices that make Bevy productive: - 1. How to set up your dev environment. - 2. Code organization. - 3. Design patterns and best practices. - 4. Testing, benchmarking and debugging. - 5. Contributing to Bevy itself. -6. Linking to further reading: official examples, `docs.rs` and (very sparingly) source code links. - -## Contributor's style guide - -When writing and reviewing learning material for the Bevy Book and Quick Start Games, please try to follow these guidelines: - -### Writing - -1. Use clear, simple language. -2. Prefer short sentences. Remove extra words. -3. **Bold** new vocabulary words where they are defined. - 1. Define them as soon as is reasonable after they are introduced. -4. Make sure your grammar and spelling are correct. -5. Avoid idioms and slang. -6. Speak directly to the reader in an approachable tone. Use "we" and "you" pronouns. -7. It can be useful to create specific, named characters to demonstrate a point. - 1. If you do, pick a pronoun set for them and stick to it. - 2. Otherwise, use "they/them" third-person pronouns to refer to the reader or others. -8. Keep humor light. - 1. Avoid off-color or offensive humor. - 2. Be mindful not to overuse in-jokes or cultural references. - 3. Don't drag your jokes out: that's not what the audience is here to read. - -### Organizational - -1. Carefully organize your work into separate pages, headings, paragraphs and code blocks. -2. Clearly signal when you are explaining a concept in technical depth so it can be skipped. -3. Use lists, numbered lists and sub-lists to present information in bite-sized ways. - 1. Refer back to these items by number! -4. Provide plenty of links, but be sure that what you are linking to is obvious by context. - 1. Link to other sections of the book / example / web page when you mention them. - 2. Always link to the most specific location you can, whether that's a section on a page or a method on a struct. - 3. Use the `latest` tag when linking to Bevy docs and source code so it won't go stale every time the version is updated. - 4. When linking to detailed explanations or discussions, summarize the most important points in addition to providing a link. - -### Technical - -1. All examples must be able to be compiled and run. -2. Prefer game-relevant, descriptive examples and variable names over generic ones like `MyEvent`. Avoid meaningless names like `foo` at all times. -3. It's good practice to break your code into blocks with comments or explanatory text, but you need to link to a cohesive, copy-able whole at the end. -4. Examples must pass Bevy's standard `clippy` lints. -5. The polish level of your examples should correspond to the point you're trying to make. - 1. If you're demonstrating a new feature, show only the most basic syntax as locally as possible. - 2. When trying to explain how a game can be made, organize and polish your code to showcase best practices. - 3. Lack of polish should serve an end: don't show bad or sloppy practices without a good reason. - 4. Showing how (and why!) to refactor your code is a very powerful teaching tool. -6. Stick to a consistent style (e.g. for loops vs map) within each example. -7. If you need to give advice that will only matter to some of your audience (e.g. how to handle an edge case, or support a specific platform), do so in a clearly marked aside or list. -8. Examples should not use or rely on third-party plugins. -These may be appropriate to link in "next steps" however at the end of the examples. - 1. Third-party crates should be limited to the most essential, such as `rand`. -9. If additional code block attributes like `no_run` or `hide-lines=x-y` need to be specified, you should always order these so that the language is the last attribute. If we would specify `rust,no_run` the syntax highlighting wouldn't work, but changing it to `no_run,rust` makes it work. -10. To validate local code changes you can either `./learning-code-examples/validate_examples.sh` from anywhere, or from the project's root `cd learning-code-examples && cargo check --examples && cargo clippy --examples && cargo fmt --check`. -11. To make sure your web-based files (html, markdown) are formatted correctly run the commands: - - ``` - markdownlint -f -c .github/linters/.markdown-lint.yml . - djlint - typos - ``` - - in the root directory of your local Bevy website repository. This will format markdown files and tell you the issues in HTML files. In order to run the command you should install `markdownlint-cli`, `djlint`, and `typos-cli`. See: , , and . Note that the CI also includes `editorconfigchecker` but there isn't an easy way to run this manually, so you should instead rely on CI to validate files with this tool. -12. To reference Rust API docs you can use markdown's reference-style links like so: - [`HashMap`] - - ```md - [`HashMap`] - - [`HashMap`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html - ``` - - [`HashMap`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html +See our Contributing Guide [in the repository](content/learn/contribute/introduction.md), or [on the site](https://bevyengine.org/learn/contribute/introduction). diff --git a/Cargo.lock b/Cargo.lock index 979daa8d1d..41780f1929 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -2321,6 +2321,7 @@ dependencies = [ "serde", "serde_json", "thiserror", + "toml 0.8.19", "ureq", ] @@ -4731,6 +4732,18 @@ dependencies = [ "toml_edit 0.19.15", ] +[[package]] +name = "toml" +version = "0.8.19" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "a1ed1f98e3fdc28d6d910e6737ae6ab1a93bf1985935a1193e68f93eeb68d24e" +dependencies = [ + "serde", + "serde_spanned", + "toml_datetime", + "toml_edit 0.22.20", +] + [[package]] name = "toml_datetime" version = "0.6.8" @@ -4771,6 +4784,8 @@ source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "583c44c02ad26b0c3f3066fe629275e50627026c51ac2e595cca4c230ce1ce1d" dependencies = [ "indexmap", + "serde", + "serde_spanned", "toml_datetime", "winnow 0.6.18", ] diff --git a/config.toml b/config.toml index 38e9358b76..ffa40f5cc9 100644 --- a/config.toml +++ b/config.toml @@ -7,12 +7,14 @@ title = "Bevy Engine" # Whether to automatically compile all Sass files in the sass directory compile_sass = true +# When set to "true", the generated HTML files are minified. +minify_html = true + # Whether to build a search index to be used later on by a JavaScript library build_search_index = true -generate_feed = true -rss_limit = 1000 -highlight_theme = "charcoal" +generate_feeds = true +feed_limit = 1000 taxonomies = [ {name = "news", feed = true}, diff --git a/content/contributing/_index.md b/content/contributing/_index.md deleted file mode 100644 index 539bff44ec..0000000000 --- a/content/contributing/_index.md +++ /dev/null @@ -1,10 +0,0 @@ -+++ -title = "Contributing" -template = "docs.html" -page_template = "docs.html" -redirect_to = "/contributing/introduction" -[extra] -# TODO: Remove both of these lines below, `status` and `public_draft`, to publish the Contributing book. -status = 'hidden' -public_draft = 1146 -+++ diff --git a/content/contributing/project-information/release-process.md b/content/contributing/project-information/release-process.md deleted file mode 100644 index d563544730..0000000000 --- a/content/contributing/project-information/release-process.md +++ /dev/null @@ -1,123 +0,0 @@ -+++ -title = "Release Process" -insert_anchor_links = "right" -[extra] -weight = 3 -+++ - -Bevy uses three-months-long development cycles, delimited by a weeks-long rolling release process. - -This means that Bevy releases a new version roughly once every three to four months. In an effort to avoid crunch and encourage sustainable development, we do not pick specific dates or deadlines. - -## Development Cycles - -During a three-month development cycle, Maintainers collect important PRs and issues into a GitHub Milestone. Issues included in the milestone are given priority, and the community generally makes a best-effort attempt to merge as many of these as possible over the duration of the cycle. - -In the lead-up to a release (generally about about two and a half months after the previous) we begin to aggressively purge the milestone of things that seem unlikely to be ready in time. The main things that tend to remain are: - -- Quick and easy features under active development. -- Fixes for important regressions or crashes. -- Large or impressive features that only need minor polish. - -When the milestone is complete, we open a new working group to handle the release preparations, publish a release candidate (ex. `0.14.0-rc.1`) and begin the release process. - -## Release Candidates - -In the run-up to a release, Bevy publishes a new release candidate about once a week. Publishing release candidates allows users to identify bugs and regressions, gives ecosystem crates time to update so they can be ready closer to release day, and provides Bevy contributors extra time to write release notes and migration guides. - -When publishing a release candidate, we also announce a general target release date. This is generally about one week out. If critical bugs or regressions are discovered during this testing window, we fix them and publish a new release candidate. Then we either - -- Announce a new date, if we believe more testing time is needed than the current window, or -- Keep the same target release date if we believe there is enough time in the current window. - -When we successfully hit a release candidate's target date, we do the final release. - -## Release Checklist - -When making a release, the Maintainers follow these checklists: - -### Minor Version - -#### Minor Pre-release - -1. Check regressions tag. -2. Check appropriate milestone and close it. -3. Check GitHub Projects page for staleness. -4. Update change log. -5. Create migration guide. -6. Write blog post. -7. Update book. -8. Bump version number for all crates, using the "Release" workflow. - 1. Change the commit message to be nicer. -9. Create tag on GitHub. -10. Edit GitHub Release. Add links to the `Release announcement` and `Migration Guide`. -11. Bump `latest` tag to most recent release. -12. Run [the `update-screenshots` workflow] to update screenshots. *This will block blog post releases (and take ~40 minutes) so do it early*. -13. Run [the `build-wasm-examples` workflow] to update Wasm examples. - -#### Minor Release - -1. Release on crates.io using `bash tools/publish.sh` -2. Announce on: - 1. HackerNews - 2. Twitter - 3. Reddit: /r/bevy, /r/rust, /r/rust_gamedev - 4. Discord: Bevy, Game Development in Rust, Rust Programming Language Community - 5. This Month in Rust Game Development newsletter - 6. This Week in Rust newsletter - -#### Minor Post-release - -1. Bump version number for all crates to next versions, as `0.X-dev`, using the "Post-release version bump" workflow, to ensure properly displayed version for [Dev Docs](https://dev-docs.bevyengine.org/bevy/index.html). -2. Update Bevy version used for the Bevy website's `learning-code-examples` tool (code example validation and formatting for the learning materials) to latest release. - -### Patch - -#### Patch Pre-release - -1. Check appropriate milestone. -2. Close the milestone, open the next one if anything remains and transfer them. -3. Bump version number for all crates, using [the command from the "Release" workflow] locally, with `patch` for the new version. - - Change the commit message to be nicer. -4. Create tag on GitHub. -5. Edit GitHub Release. Add link to the comparison between this patch and the previous version. -6. Bump `latest` tag to most recent release. -7. Run the [`update-screenshots` workflow] to update screenshots. -8. Run this [`build-wasm-examples` workflow] to update Wasm examples. - -#### Patch Release - -1. Release on crates.io - - `bash tools/publish.sh` -2. Announce on: - 1. Discord: Bevy - -#### Patch Post-Release - -### Release Candidate - -#### RC Pre-Release - -1. Check appropriate milestone. -2. Create a branch for the release. -3. Bump version number for all crates, using [the command from the "Release" workflow] locally, with `rc` for the new version. - - Change the commit message to be nicer. -4. Create tag on GitHub. -5. Edit GitHub Release. Add link to the comparison between this rc and the previous version. - -#### RC Release - -1. Release on crates.io - - `bash tools/publish.sh` -2. Announce on: - 1. Discord: Bevy, #dev-announcements - -#### RC Post-Release - -1. Update Bevy version used for the Bevy website's `learning-code-examples` tool (code example validation and formatting for the learning materials) to latest release. -Commit suggestion -Add suggestion to batch``` - -[`update-screenshots` workflow]: https://github.com/bevyengine/bevy-website/actions/workflows/update-screenshots.yml -[`build-wasm-examples` workflow]: https://github.com/bevyengine/bevy-website/actions/workflows/build-wasm-examples.yml -[the command from the "Release" workflow]: https://github.com/bevyengine/bevy/blob/main/.github/workflows/release.yml diff --git a/content/donate/faq/index.md b/content/donate/faq/index.md deleted file mode 100644 index a5771c03d9..0000000000 --- a/content/donate/faq/index.md +++ /dev/null @@ -1,31 +0,0 @@ -+++ -title = "Donate FAQ" -template = "page.html" -+++ - -## I donated at a level that lets me add my name / link / logo to the credits. How do I do that? - -Tiers that support names and links allow you to specify them directly in the Stripe form. If you did not do this, contact us at with that information and we'll get you added! - -Tiers that support logos require reaching out to . Send us your logo and your link and we'll add you! - -## How do I cancel my donation subscription? - -If you paid through Stripe (currently the only way to set up a donation subscription), just [visit this link](https://billing.stripe.com/p/login/7sI3ee5OXbI7dgIaEE) and enter the email you used to set up the subscription. - -## I donated at a tier that adds me to the credits, can I use whatever name / logo / link I want? - -We reserve the right to refuse to list any name / link / logo for any reason. If it is obnoxious, offensive, rude, or a violation of our [Code of Conduct](https://github.com/bevyengine/bevy/blob/main/CODE_OF_CONDUCT.md), expect us to refuse to list it. - -Please only use names, logos, and links that you have the right and permission to use. - -## I sponsored but the metrics / names / logos on the donate page haven't updated! - -Please wait a little. It might take up to eight hours for the automatic update to add you to the credits. - -## How are the metrics on the donation page calculated? - -The monthly dollar amount is the "raw pledged amount for active monthly donations". This means two things: - -1. This number is "pre Stripe fees". This includes credit card fees and Stripes "processing fees", which vary per payment type. -2. This is the amount we _expect_ to get each month. In practice the payouts will be less, once chargebacks and cancellations are processed. diff --git a/content/donate/options/index.md b/content/donate/options/index.md new file mode 100644 index 0000000000..9584ca9a16 --- /dev/null +++ b/content/donate/options/index.md @@ -0,0 +1,63 @@ ++++ +title = "Donate" +template = "donate-options.html" +[extra] +header_message = "Donate" ++++ + +## Should I donate through Every.org or Stripe? + +The short answer is "use Every.org if you can". Prefer paying directly through your bank if you want to avoid payment processor fees. + +[Every.org](https://every.org/bevy-foundation), like Bevy Foundation, is a non-profit 501(c)(3) public charity, and they only work with other charities. +They are our preferred donation platform because they charge _no fees_, other than the baseline payment provider fees. This is literally as good as it can get. +If you pay with your bank account, 100% of your donation goes to the Bevy Foundation. If you use one of their other payment methods (credit card, PayPal, Google Pay, Apple Pay, etc), +then they charge the baseline fees that those providers charge. + +Every.org also supports custom one-time donations, so if you want to do one of those, you should use Every.org. + +Stripe does also cut us a deal as a non profit for card transactions (we pay 2.2% + 30 cents instead of 2.9% + 30 cents). However for bank transactions, they charge 0.8%, +and for _all monthly subscriptions_ they add another 0.5% charge (soon to be 0.7%). These fees add up, so only use Stripe if you have to, and prefer paying with your bank account! + +## Why can't I use Every.org for Bronze membership? + +Every.org has a minimum payment of $10, so we can't offer Bronze through them. This is why the Bronze link on the donate page defaults to Stripe instead of Every.org. + +## I donated at a level that lets me add my name / link / logo to the credits. How do I do that? + +You have three options: + +1. If you donated via Every.org and opted for a public donation, your name will be included automatically. If you set the relevant form values on Stripe, the name and link will be used. If you donated at a level that includes a logo, or you would like to change any of the names / link values that have already been set, see the next two options. +2. Reach out to with the values you want and we will add them. Please provide your name and donation tier to help us find your donation info. +3. You can [set them yourself here](https://github.com/bevyengine/bevy-donors) by submitting a pull request. See the "Adding/Updating Donor Info" section of the readme. + +## Can I make a one-time donation instead of monthly? + +Yup! Every.org supports this. Click the "custom" link in the table above and select "one time". + +## How do I cancel my donation subscription? + +If you paid through Every.org, log in to their website and cancel through their portal. You can find that here: . + +If you paid through Stripe (currently the only way to set up a donation subscription), just [visit this link](https://billing.stripe.com/p/login/7sI3ee5OXbI7dgIaEE) and enter the email you used to set up the subscription. + +## I want a donation receipt, how do I get one? + +For both platforms (Every.org and Stripe), you will get emailed donation receipts after successful donations. + +## I donated at a tier that adds me to the credits, can I use whatever name / logo / link I want? + +We reserve the right to refuse to list any name / link / logo for any reason. If it is obnoxious, offensive, rude, or a violation of our [Code of Conduct](https://github.com/bevyengine/bevy/blob/main/CODE_OF_CONDUCT.md), expect us to refuse to list it. + +Please only use names, logos, and links that you have the right and permission to use. + +## I sponsored but the metrics / names / logos on the donate page haven't updated! + +Please wait a little. It might take up to eight hours for the automatic update to add you to the credits. + +## How are the metrics on the donation page calculated? + +The monthly dollar amount is the "raw pledged amount for active monthly donations". This means two things: + +1. This number is "pre payment processor and platform fees". This includes credit card fees and Stripes "processing fees", which vary per payment type. +2. This is the amount we _expect_ to get each month. In practice the payouts will be less, once chargebacks and cancellations are processed. diff --git a/content/donate/tiers.toml b/content/donate/tiers.toml index 694c20f635..be0dfdca41 100644 --- a/content/donate/tiers.toml +++ b/content/donate/tiers.toml @@ -5,21 +5,24 @@ name = "Bronze" amount = 5 sponsor_tier = false icon = "/assets/sponsor_badges/bronze.svg" -donate_link = "https://buy.stripe.com/5kA7vS7tPeXJ38A7ss" +stripe_link = "https://buy.stripe.com/5kA7vS7tPeXJ38A7ss" +every_org_missing = "Every.org has a $10 minimum" [[tier]] name = "Silver" amount = 10 sponsor_tier = false icon = "/assets/sponsor_badges/silver.svg" -donate_link = "https://buy.stripe.com/9AQ5nK01neXJ4cE001" +stripe_link = "https://buy.stripe.com/9AQ5nK01neXJ4cE001" +every_org_link = "https://www.every.org/bevy-foundation?amount=10&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=Silver&frequency=MONTHLY&utm_campaign=donate-link#/donate" [[tier]] name = "Gold" amount = 25 sponsor_tier = false icon = "/assets/sponsor_badges/gold.svg" -donate_link = "https://buy.stripe.com/9AQ5nKaG1cPB5gI28a" +stripe_link = "https://buy.stripe.com/9AQ5nKaG1cPB5gI28a" +every_org_link = "https://www.every.org/bevy-foundation?amount=25&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=Gold&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_name = true [[tier]] @@ -27,7 +30,8 @@ name = "Platinum" amount = 50 sponsor_tier = false icon = "/assets/sponsor_badges/platinum.svg" -donate_link = "https://buy.stripe.com/eVa3fC4hD2aX7oQeUX" +stripe_link = "https://buy.stripe.com/eVa3fC4hD2aX7oQeUX" +every_org_link = "https://www.every.org/bevy-foundation?amount=50&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=Platinum&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_name = true [[tier]] @@ -35,7 +39,8 @@ name = "Titanium" amount = 100 sponsor_tier = false icon = "/assets/sponsor_badges/titanium.svg" -donate_link = "https://buy.stripe.com/5kAbM8cO9g1NfVm004" +stripe_link = "https://buy.stripe.com/5kAbM8cO9g1NfVm004" +every_org_link = "https://www.every.org/bevy-foundation?amount=100&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=Titanium&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_name = true reward_link = true @@ -44,7 +49,8 @@ name = "Diamond" amount = 250 sponsor_tier = false icon = "/assets/sponsor_badges/diamond.svg" -donate_link = "https://buy.stripe.com/6oEaI49BX16T9wY4gl" +stripe_link = "https://buy.stripe.com/6oEaI49BX16T9wY4gl" +every_org_link = "https://www.every.org/bevy-foundation?amount=250&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=Diamond&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_logo = true reward_link = true logo_height = 45 @@ -54,7 +60,8 @@ name = "Corporate Bronze" amount = 500 sponsor_tier = true icon = "/assets/sponsor_badges/bronze.svg" -donate_link = "https://buy.stripe.com/bIY7vSeWhaHt7oQ7sy" +stripe_link = "https://buy.stripe.com/bIY7vSeWhaHt7oQ7sy" +every_org_link = "https://www.every.org/bevy-foundation?amount=500&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=CorporateBronze&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_logo = true reward_link = true logo_height = 70 @@ -64,7 +71,8 @@ name = "Corporate Silver" amount = 1000 sponsor_tier = true icon = "/assets/sponsor_badges/silver.svg" -donate_link = "https://buy.stripe.com/14kcQceWh8zleRi4gn" +stripe_link = "https://buy.stripe.com/14kcQceWh8zleRi4gn" +every_org_link = "https://www.every.org/bevy-foundation?amount=1000&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=CorporateSilver&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_logo = true reward_link = true logo_height = 85 @@ -74,7 +82,8 @@ name = "Corporate Gold" amount = 2000 sponsor_tier = true icon = "/assets/sponsor_badges/gold.svg" -donate_link = "https://buy.stripe.com/fZecQcdSd6rd4cEfZ6" +stripe_link = "https://buy.stripe.com/fZecQcdSd6rd4cEfZ6" +every_org_link = "https://www.every.org/bevy-foundation?amount=2000&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=CorporateGold&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_logo = true reward_link = true logo_height = 90 @@ -84,7 +93,8 @@ name = "Corporate Platinum" amount = 4000 sponsor_tier = true icon = "/assets/sponsor_badges/platinum.svg" -donate_link = "https://buy.stripe.com/fZe03q29vdTFgZq6ox" +stripe_link = "https://buy.stripe.com/fZe03q29vdTFgZq6ox" +every_org_link = "https://www.every.org/bevy-foundation?amount=4000&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=CorporatePlatinum&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_logo = true reward_link = true logo_height = 95 @@ -94,7 +104,8 @@ name = "Corporate Titanium" amount = 6000 sponsor_tier = true icon = "/assets/sponsor_badges/titanium.svg" -donate_link = "https://buy.stripe.com/bIY03qaG1eXJ8sU8wG" +stripe_link = "https://buy.stripe.com/bIY03qaG1eXJ8sU8wG" +every_org_link = "https://www.every.org/bevy-foundation?amount=6000&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=CorporateTitanium&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_logo = true reward_link = true logo_height = 100 @@ -104,7 +115,8 @@ name = "Corporate Diamond" amount = 8000 sponsor_tier = true icon = "/assets/sponsor_badges/diamond.svg" -donate_link = "https://buy.stripe.com/00gdUg4hD6rddNe7sD" +stripe_link = "https://buy.stripe.com/00gdUg4hD6rddNe7sD" +every_org_link = "https://www.every.org/bevy-foundation?amount=8000&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=CorporateDiamond&frequency=MONTHLY&utm_campaign=donate-link#/donate" reward_logo = true reward_link = true logo_height = 120 @@ -114,7 +126,8 @@ name = "Patron" amount = 13000 sponsor_tier = true icon = "/assets/sponsor_badges/patron.svg" -donate_link = "mailto:bevyengine@gmail.com" +every_org_link = "https://www.every.org/bevy-foundation?amount=13000&theme_color=6a8fb3&method=card%2Cbank%2Cpaypal%2Cpay&designation=CorporatePatron&frequency=MONTHLY&utm_campaign=donate-link#/donate" +stripe_missing = "Not supported right now" reward_logo = true reward_link = true logo_height = 190 diff --git a/content/foundation/bylaws/index.md b/content/foundation/bylaws/index.md index a7e584e381..fb377f59b6 100644 --- a/content/foundation/bylaws/index.md +++ b/content/foundation/bylaws/index.md @@ -101,7 +101,9 @@ A Director of the Corporation present at a Board meeting at which action on any ### 5.16 Action by Board Without a Meeting -Any action which could be taken at a meeting of the Board may be taken without a meeting if a written consent setting forth the action so taken is executed by each of the Directors entitled to vote. Such written consents may be executed in two or more counterparts, each of which shall be deemed an original and all of which, taken together, shall constitute one and the same document. Any such written consent shall be inserted in the minute book as if it were the minutes of a Board meeting. For purposes of these Bylaws, “executed” means: (a) writing that is signed; or (b) an email transmission that is sent with sufficient information to determine the sender’s identity. +Any action which could be taken at a meeting of the Board may be taken without a meeting if a written consent setting forth the action so taken is executed by each of the Directors entitled to vote. Such written consents may be executed in two or more counterparts, each of which shall be deemed an original and all of which, taken together, shall constitute one and the same document. Any such written consent shall be inserted in the minute book as if it were the minutes of a Board meeting. For purposes of these Bylaws, “executed” means: (a) writing that is signed; or (b) an email transmission with sufficient information to determine the sender's identity or a Discord message or vote in an official Bevy channel or private chat where all maintainers are present." + +At the time of determining the results of a vote, "edits" to digital messages are considered invalid and the Secretary should take screenshots of the results to include in the meeting minutes. For purposes of this Section 3.16 only, "each of the Directors entitled to vote" does not include an "interested director" who abstains in writing from providing consent, where: @@ -241,7 +243,7 @@ After disclosure of the financial interest or organizational affiliation and all The minutes of the governing board and all committees with board delegated powers shall contain: 1. The names of the persons who disclosed or otherwise were found to have a financial interest or organizational affiliation in connection with an actual or possible conflict of interest, the nature of the financial interest or organizational affiliation, any action taken to determine whether a conflict of interest was present, and the governing board’s or committee’s decision as to whether a conflict of interest in fact existed. -2. The names of the persons who were present for discussions and votes relating to the transaction or arrangement, the content of the discussion, including any alternatives to the proposed transaction or arrangement, and a record of any votes taken in connection with the proceedings. +2. The names of the persons who were present for discussions and votes relating to the transaction or arrangement, the content of the discussion, including any alternatives to the proposed transaction or arrangement, and a record of any votes taken in connection with the proceedings. When a decision is not unanimous, the name of each voting board member and the content of their vote must be recorded in the minutes. ### 8.6 Compensation diff --git a/content/foundation/meeting-minutes/2024-02-03/index.md b/content/foundation/meeting-minutes/2024-02-03/index.md index 6fea73a737..c552c6865d 100644 --- a/content/foundation/meeting-minutes/2024-02-03/index.md +++ b/content/foundation/meeting-minutes/2024-02-03/index.md @@ -81,7 +81,7 @@ Unanimously approved. Discussed how to validate meeting minutes. -Agreed on storing meeting minutes on Github on `bevy-website repo`, and approved by board members via PR approval. +Agreed on storing meeting minutes on GitHub on `bevy-website repo`, and approved by board members via PR approval. ## Transferring the ownership of the bevyengine.org domain to the Foundation diff --git a/content/foundation/meeting-minutes/actions-without-meeting/bevy_playground_logo_usage.png b/content/foundation/meeting-minutes/actions-without-meeting/bevy_playground_logo_usage.png new file mode 100644 index 0000000000..8f477c3223 Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/bevy_playground_logo_usage.png differ diff --git a/content/foundation/meeting-minutes/actions-without-meeting/deprecating_legacy_sponsors.png b/content/foundation/meeting-minutes/actions-without-meeting/deprecating_legacy_sponsors.png new file mode 100644 index 0000000000..37b54e3150 Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/deprecating_legacy_sponsors.png differ diff --git a/content/foundation/meeting-minutes/actions-without-meeting/increasing_alice_salary.png b/content/foundation/meeting-minutes/actions-without-meeting/increasing_alice_salary.png new file mode 100644 index 0000000000..eebd7cd915 Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/increasing_alice_salary.png differ diff --git a/content/foundation/meeting-minutes/actions-without-meeting/index.md b/content/foundation/meeting-minutes/actions-without-meeting/index.md new file mode 100644 index 0000000000..5f829f86cc --- /dev/null +++ b/content/foundation/meeting-minutes/actions-without-meeting/index.md @@ -0,0 +1,161 @@ ++++ +title = "Actions by the Board without a Meeting" +date = 2024-09-16 +authors = ["Alice I. Cecile"] +[extra] +github = "alice-i-cecile" ++++ + + + +Not all actions taken by the board require a formal meeting! +For the sake of transparency though, we've recorded the actions of the board performed without a meeting here, in chronological order. +Screenshots are provided for each decision, although for feasibility reasons only the final vote tally is recorded in them (only thumbs up / thumbs down reactions count). + +The language here is often informal, but as Secretary I've captured it directly for maximal transparency and accuracy. +I've used `[]` brackets to fill in missing context to quotes when it was natural, and have added a `Context` section where it is not. + +Only actions where a vote occurs is recorded, and all such votes will be reported (along with the votes of each board member), regardless of if an initiative passes. +Generally speaking, the Bevy maintainers only act "as the board" when handling foundation business, and vote on matters of relatively high importance or those involving finances. +Ordinary moderation decisions don't rise to the level of the board, and technical discussion is handled in the open. + +The board acts with a majority vote, and a recorded "unanimous" vote means that all board members at the time voted the same way with no absences or abstentions. + +## 2024-04-15: Using Thera as our Employer of Record + +![Using Thera as our Employer of Record](thera_employer_of_record.png) + +**Context:** In order to readily employee folks from across the world, the Bevy Foundation uses an [employer of record](https://www.oysterhr.com/glossary/eor) to handle local compliance, taxation and benefits. + +**Proposal:** Are we good to move forward with onboarding \[with thera\], given that \[the cost will be $400/month, $200 cheaper than that of Deel\]? + +**Proposed by:** Carter Anderson + +**Votes:** Yes from Rob Swain, Carter Anderson, Alice I. Cecile, François Mockers. No vote from James Liu. + +## 2024-04-15: Initial job titles + +![Initial job titles](initial_job_titles.png) + +**Proposal:** All in favor of Project Lead (me once we hire me), Staff Engineer (soon to be Alice + future maintainer hires), and Principal for SME hires? + +**Proposed by:** Carter Anderson + +**Votes:** Unanamious yes + +## 2024-04-18: Usage of the Bevy logo by the unofficial Bevy Playground + +![Usage of the Bevy logo by the unofficial Bevy Playground](bevy_playground_logo_usage.png) + +**Proposal:** Thumbs up to this message to vote yes to approving [use of the logo](https://discordapp.com/channels/691052431525675048/745355529777315850/1230635309906137098) for [Bevy Playground](https://learnbevy.com/playground). + +**Proposed by:** Alice I. Cecile + +**Votes:** Yes by Carter Anderson, Alice I. Cecile, and Rob Swain. No vote from James Liu and Francois. + +## 2024-05-02: Sick leave documentation policy + +![Sick leave documentation policy](sick_leave_documentation_policy.png) + +**Proposal:** Should Bevy Foundation employees require documentation for sick leave? + +**Proposed by:** Carter Anderson![alt text](image.png) + +**Votes:** No from Rob Swain, Carter Anderson, Alice I. Cecile, James Liu. No vote from François Mockers. + +## 2024-06-16: Repaying Cart for initial deposit into bank account + +![Repaying Cart for initial deposit into bank account](repaying_cart_initial_deposit.png) + +**Context:** The Bevy bank account needed funds in it to be opened. Cart lent the Foundation $2000 USD from his personal account to cover this. + +**Proposal:** I do also think we're in a good enough spot reserves-wise (12k USD) for me to reclaim the 2k I added at the beginning. Are we ok with that? + +**Proposed by:** Carter Anderson + +**Votes:** Yes by Alice I. Cecile, Rob Swain and François Mockers. No vote from James Liu. Carter Anderson abstained. + +## 2024-07-08: Increasing Alice's salary + +![Increasing Alice's salary](increasing_alice_salary.png) + +**Context:** + +> Cart: Alrighty it is definitely time to bump Alice's pay. Consider this a start of one of our "async chat-driven board meetings". Here is my proposal, given the current numbers. +> +> First, lets look at our current numbers: +> Our current net volume (aka what we take home after stripe fees, credit card fees, failed payments / disputes, etc) for a 4 week period on Stripe is 7,884 USD +> We have 15,932 USD in our account (with the next monthly Thera charge coming up on the 11th) +> Alice's current monthly "gross" income is 3,000 CAD +> We are charged 2,796 USD each month, which translates to about 3,813 CAD. The 813 CAD difference includes the 400 USD (545.65 CAD) Thera EOR fee, plus additional canadian employer taxes. +> Alice currently makes 675 USD from Github Sponsors +> I currently make 4245 USD from Github Sponsors. +> Given the current 7,884 USD, I think we should leave ~800 USD of wiggle room each month to account for fluctuations. That (in combination with our current 15,932 USD buffer) seems more than safe enough. That means we have 7,884 - 800 = 7,084 USD to distribute each month. +> Lets talk "auto-balance algorithm": +> +> On the topic of taxes: I think it is fair to say that taxes are a cost that is "paid" by the receiver of the funds, given that they pay into public benefits that the receiver benefits from. So when calculating auto-balance, it makes sense to do that pre-tax. +On the topic of Thera fees: I think this cost should be split evenly across those getting paid, as the choice to incorporate in the United States was arbitrary and people outside of the united states should not be penalized for it. Put another way, this is a cost "paid by the Foundation prior to making payouts". +> +> > So if we were to start auto-balancing now, this would be the calculation (in USD): +> +> $7,884 (currently monthly net income) - $800 (buffer) = $7,084 +> $7,084 - $400 (current Thera EOR) = $6,684 +> $6,684 / 2 = $3,342 +> $4,245 (current Cart Github Sponsors) + $3,342 = $7,587 (Cart's pre auto balance total) +> $675 (current Alice Github Sponsors) + $3,342 = $4,017 (Alice's pre auto balance total) +> $7,587 - $4,017 = $3,570 (pre-auto balance difference) +> $3,570 / 2 = $1,785 (amount to redistribute to Alice) +> $4,017 + $1,785 = $5,802 (Alice's post-auto-balance total) +> $7,587 - $1,785 = $5,802 (Cart's post-auto-balance total) +> $5,802 - $675 = $5,127 (Bevy Foundation payment to Alice) +> $5,802 - $4,245 = $1,557 (Bevy Foundation payment to Cart) +> $5,127 + $1,557 = $6,684 (proof that this adds up to the funds allocated for this by the foundation) +> +> From there, we need to sort out Alice's target "gross" income, based on all Canadian fees: +> +> Based on the current numbers: +> 3,000 CAD gross income +> 2,796.62 USD monthly cost to foundation +> 2,796.62 USD - 400 USD (EOR cost) = 2,396.62 USD (cost to foundation minus Thera EOR) +> 2,396.62 USD = 3,269.65 CAD at time of writing +> 3,269.65 CAD / 3,000 CAD = 1.089883333 (canadian overhead multiplier) +> +> +> 5,127 USD ~= 6,994.51 CAD at the time of writing +> 6,994.51 CAD / 1.089883333 (canadian overhead multiplier) = 6,417.67 CAD (Alice monthly gross) +> +> Note that I am still not quite prepared on the "legal" side to take my cut, but I think we should set Alice's payment according to this rate, as I'm not certain how possible lowering monthly income arbitrarily is. We can sort out what to do with the extra funds later (ex: pay out as "fixup" bonuses, or we can discuss alternatives). + +**Proposal:** So the proposal is: increase Alice's monthly payments to $6,417.67 CAD ($4,705.28 USD) as soon as Thera can make it possible. Vote on this comment with 👍 or 👎 to officially approve this proposal. Feel free to discuss first if you want to amend the proposal / notice any discrepancies. + +**Votes:** Alice I. Cecile abstains. All others voted yes. + +## 2024-07-16: Deprecating legacy sponsors + +![Deprecating legacy sponsors](deprecating_legacy_sponsors.png) + +**Proposal:** Also: I think it is time to deprecate the "legacy sponsors" section. I've prepped [a branch](https://github.com/bevyengine/bevy-website/pull/1564) but I won't create the PR until we agree + +**Proposed by:** Carter Anderson + +**Votes:** Yes by Alice I. Cecile, Rob Swain and François Mockers. No vote from Carter Anderson or James Liu. + +## 2024-09-09: More relaxed voting rules + +![More relaxed voting rules](more_relaxed_voting_rules.png) + +**Proposal:** We should change "(b) an email transmission that is sent with sufficient information to determine the sender’s identity"" in section 5.16 of the Bevy Foundation Bylaws to "(b) an email transmission with sufficient information to determine the sender's identity or a Discord message or vote in an official Bevy channel or private chat where all maintainers are present." At the time of determining the results of a vote, "edits" to digital messages are considered invalid and the Secretary should take screenshots of the results to include in the meeting minutes. + +**Proposed by:** Carter Anderson + +**Votes:** Yes by Carter Anderson, Alice I. Cecile, Rob Swain and François Mockers. No vote by James Liu. + +## 2024-09-09: Recording who voted for which motions in the minutes + +![Recording who voted for which motions in the minutes](recording_who_voted.png) + +**Proposal:** We should change "The names of the persons who were present for discussions and votes relating to the transaction or arrangement, the content of the discussion, including any alternatives to the proposed transaction or arrangement, and a record of any votes taken in connection with the proceedings." in section 8.5 of the Bevy Foundation Bylaws to "The names of the persons who were present for discussions and votes relating to the transaction or arrangement, the content of the discussion, including any alternatives to the proposed transaction or arrangement, and a record of any votes taken in connection with the proceedings. When a decision is not unanimous, the name of each voting board member and the content of their vote must be recorded in the minutes." + +**Proposed by:** Carter Anderson + +**Votes:** Yes by Carter Anderson, Alice I. Cecile, Rob Swain and François Mockers. No vote by James Liu. diff --git a/content/foundation/meeting-minutes/actions-without-meeting/initial_job_titles.png b/content/foundation/meeting-minutes/actions-without-meeting/initial_job_titles.png new file mode 100644 index 0000000000..79d8c88784 Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/initial_job_titles.png differ diff --git a/content/foundation/meeting-minutes/actions-without-meeting/more_relaxed_voting_rules.png b/content/foundation/meeting-minutes/actions-without-meeting/more_relaxed_voting_rules.png new file mode 100644 index 0000000000..4dea24119c Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/more_relaxed_voting_rules.png differ diff --git a/content/foundation/meeting-minutes/actions-without-meeting/recording_who_voted.png b/content/foundation/meeting-minutes/actions-without-meeting/recording_who_voted.png new file mode 100644 index 0000000000..3943019504 Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/recording_who_voted.png differ diff --git a/content/foundation/meeting-minutes/actions-without-meeting/repaying_cart_initial_deposit.png b/content/foundation/meeting-minutes/actions-without-meeting/repaying_cart_initial_deposit.png new file mode 100644 index 0000000000..f9f387604b Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/repaying_cart_initial_deposit.png differ diff --git a/content/foundation/meeting-minutes/actions-without-meeting/sick_leave_documentation_policy.png b/content/foundation/meeting-minutes/actions-without-meeting/sick_leave_documentation_policy.png new file mode 100644 index 0000000000..653677660b Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/sick_leave_documentation_policy.png differ diff --git a/content/foundation/meeting-minutes/actions-without-meeting/thera_employer_of_record.png b/content/foundation/meeting-minutes/actions-without-meeting/thera_employer_of_record.png new file mode 100644 index 0000000000..57a8fc463d Binary files /dev/null and b/content/foundation/meeting-minutes/actions-without-meeting/thera_employer_of_record.png differ diff --git a/content/learn/book/ecs/_index.md b/content/learn/book/ecs/_index.md index b926df7fb6..da0b58fa72 100644 --- a/content/learn/book/ecs/_index.md +++ b/content/learn/book/ecs/_index.md @@ -9,7 +9,7 @@ status = 'hidden' In Bevy, game objects are stored as **entities**, whose data is stored as **components**. **Systems** operate on this data, modifying the **world** to carry out the behavior that brings your game to life. -Together, these these form the basis of Bevy's **ECS**, which unsurprisingly stands for ["Entity-Component-System"](https://en.wikipedia.org/wiki/Entity_component_system). +Together, these form the basis of Bevy's **ECS**, which unsurprisingly stands for ["Entity-Component-System"](https://en.wikipedia.org/wiki/Entity_component_system). Let's go over the most important definitions: - **World:** A unifying collection of all of the data stored in the ECS. diff --git a/content/learn/contribute/_index.md b/content/learn/contribute/_index.md new file mode 100644 index 0000000000..32cea68980 --- /dev/null +++ b/content/learn/contribute/_index.md @@ -0,0 +1,6 @@ ++++ +title = "Contributing" +template = "docs.html" +page_template = "docs.html" +redirect_to = "/learn/contribute/introduction" ++++ diff --git a/content/contributing/helping-out/_index.md b/content/learn/contribute/helping-out/_index.md similarity index 53% rename from content/contributing/helping-out/_index.md rename to content/learn/contribute/helping-out/_index.md index cb4cfc6639..a588a14778 100644 --- a/content/contributing/helping-out/_index.md +++ b/content/learn/contribute/helping-out/_index.md @@ -1,7 +1,7 @@ +++ title = "Helping out" template = "docs.html" -redirect_to = "/contributing/helping-out/how-you-can-help" +redirect_to = "/learn/contribute/helping-out/how-you-can-help" [extra] weight = 2 +++ diff --git a/content/contributing/helping-out/creating-examples.md b/content/learn/contribute/helping-out/creating-examples.md similarity index 91% rename from content/contributing/helping-out/creating-examples.md rename to content/learn/contribute/helping-out/creating-examples.md index 9af47ee6f0..a857456cb3 100644 --- a/content/contributing/helping-out/creating-examples.md +++ b/content/learn/contribute/helping-out/creating-examples.md @@ -20,7 +20,7 @@ Run `cargo run -p build-templated-pages -- build-example-page` to do this automa Use a generous sprinkling of keywords in your description: these are commonly used to search for a specific example. See the [example style guide](#style-guide) to help make sure the style of your example matches what we're already using. -More complex demonstrations of functionality are also welcome, but these should be submitted to [bevy-assets](https://github.com/bevyengine/bevy-assets). +More complex demonstrations of functionality are also welcome, but these should be submitted to [`bevy-assets`](https://github.com/bevyengine/bevy-assets). ## Style guide @@ -30,7 +30,7 @@ Please adhere to the following guidelines when creating or updating an example. 1. Examples should live in an appropriate subfolder of `/examples`. 2. Examples should be a single file if possible. -3. Assets live in `/assets`. Try to avoid adding new assets unless strictly necessary to keep the repo small. Don't add "large" asset files. +3. Assets live in `/assets`. Try to avoid adding new assets unless strictly necessary to keep the repository small. Don't add "large" asset files. 4. Each example should try to follow this order: 1. Imports 2. A `fn main()` block @@ -64,6 +64,13 @@ Please adhere to the following guidelines when creating or updating an example. 6. Prefer structs with named fields over tuple structs except in the case of single-field wrapper types. 7. Use enum-labels over string-labels for app / schedule / etc. labels. +### Visual guidelines + +Examples may be displayed in the [example showcase](https://bevyengine.org/examples/) and a consistent style helps keep things tidy there. + +1. Use the default `ClearColor` and `WindowResolution` unless absolutely necessary. +2. "Instruction Text" should use the default font, color, and size. It should be inset 12 pixels from the edge of the window. + ### "Feature" examples These examples demonstrate the usage of specific engine features in clear, minimal ways. diff --git a/content/contributing/helping-out/how-you-can-help.md b/content/learn/contribute/helping-out/how-you-can-help.md similarity index 61% rename from content/contributing/helping-out/how-you-can-help.md rename to content/learn/contribute/helping-out/how-you-can-help.md index 74d5980153..561cbcaec6 100644 --- a/content/contributing/helping-out/how-you-can-help.md +++ b/content/learn/contribute/helping-out/how-you-can-help.md @@ -14,10 +14,10 @@ No matter how experienced you are with Bevy and Rust, or what your level of comm Ultimately, Bevy is a tool that's designed to help people make cool games. Just by *using* Bevy you're helping us catch bugs, prioritize new features, polish off rough edges, and promote the project. -If you're using Bevy, we want to hear from you! Don't hesitate to ask for support on [Github Discussions], [Discord], or [Reddit]. Once you've made something that you're proud of, feel free to drop a link, video, or screenshot in `#showcase` on [Discord]! If you release a game on [itch.io] we'd be thrilled if you tagged it with `bevy`. +If you're using Bevy, we want to hear from you! Don't hesitate to ask for support on [GitHub Discussions], [Discord], or [Reddit]. Once you've made something that you're proud of, feel free to drop a link, video, or screenshot in `#showcase` on [Discord]! If you release a game on [itch.io] we'd be thrilled if you tagged it with `bevy`. {% callout() %} -Think you've found a bug, missing documentation, or a feature that would help you make better games? [File an issue](https://github.com/bevyengine/bevy/issues/new/choose) on the main `bevy` repo! Take a look at the chapter on [Reporting Issues](@/contributing/helping-out/reporting-issues.md) to learn more. +Think you've found a bug, missing documentation, or a feature that would help you make better games? [File an issue](https://github.com/bevyengine/bevy/issues/new/choose) on the main `bevy` repo! Take a look at the chapter on [Reporting Issues](@/learn/contribute/helping-out/reporting-issues.md) to learn more. {% end %} [GitHub Discussions]: https://github.com/bevyengine/bevy/discussions @@ -29,43 +29,41 @@ Think you've found a bug, missing documentation, or a feature that would help yo **One of the most valuable things you can do is review other people's work.** Bevy relies on community code review to keep the code quality high and the maintenance burden low. Absolutely anyone is welcome to leave reviews, and all reviews are treated with equal weight. -You don't need to be an Elder Rustacean to be useful here: anyone can catch missing tests, unclear docs, logic errors, and so on. If you're new to Rust or Bevy, submitting reviews is great way to learn things and acquaint yourself with the internals of the engine. +You don't need to be an Elder Rustacean to be useful here: anyone can catch missing tests, unclear docs, logic errors, and so on. If you're new to Rust or Bevy, submitting reviews is a great way to learn things and acquaint yourself with the internals of the engine. If you do have specific skills (e.g. advanced familiarity with `unsafe` code, rendering knowledge, or web development experience) or experience with a specific problem, that's fantastic! We suggest trying to prioritize those areas to ensure we get appropriate expertise where we need it. -Not even our Project Leads and Maintainers are exempt from reviews! By giving feedback on this work (and related supporting work), you can help us make sure our releases are both high-quality and timely. +Not even our Project Lead and Maintainers are exempt from reviews! By giving feedback on this work (and related supporting work), you can help us make sure our releases are both high-quality and timely. {% callout() %} -Interested in reviewing but don't know where to start? Check out [Reviewing Pull Requests](TODO)! +Interested in reviewing, but don't know where to start? Check out [Reviewing Pull Requests](@/learn/contribute/helping-out/reviewing-pull-requests.md)! {% end %} ## Joining a Working Group -Bevy's active initiatives are organized into *temporary working groups*: public, open-membership teams where people work together to tackle a sizeable, well-scoped goal. Each working group coordinates through a dedicated forum-channel on [Discord], but they may also create issues or use project boards to organize and track their progress. +Bevy's active initiatives are organized into *temporary working groups*: public, open-membership teams where people work together to tackle a sizeable, well-scoped goal. Each working group coordinates through a [dedicated forum-channel](https://discord.com/channels/691052431525675048/1235758970703188008) on [Discord], but they may also create issues or use project boards to organize and track their progress. -You should consider joining a working group if you're interested in contributing but don't know where to start or what to work on. Choosing one and asking how to help can be a fantastic way to get up to speed and be immediately useful. +You should consider joining a working group if you're interested in contributing, but don't know where to start or what to work on. Choosing one and asking how to help can be a fantastic way to get up to speed and be immediately useful. There are no special requirements to participate in a working group — no applications, formal membership list, or even leadership. Anyone can help, and you should expect to compromise and work together with others to bring your shared vision to life. Working groups are *spaces*, not clubs. {% callout() %} -Anyone can start a working group! Check out [Working Groups](TODO) for more information about the process and requirements. +Anyone can start a working group! Check out [Working Groups](@/learn/contribute/project-information/working-groups.md) for more information about the process and requirements. {% end %} ## Contributing Code -We love getting code contributions from the community, and there's plenty of work to go around! If you want to code but don't know what to work on, you should take a look at the open issues. The page on [Triage](@/contributing/reference/triage.md) details several tags that you can use to filter issues by difficulty and area. +We love getting code contributions from the community, and there's plenty of work to go around! If you want to code, but don't know what to work on, you should take a look at the open issues. The page on [Triage](@/learn/contribute/reference/triage.md) details several tags that you can use to filter issues by difficulty and area. -If you already know what you want to work on, all you have to do is make your changes and submit a pull request! The page on [Your First Pull Request](TODO) is there to help if you get stuck. +If you already know what you want to work on, all you have to do is make your changes and submit a pull request! The page on [Opening Pull Requests](@/learn/contribute/helping-out/opening-pull-requests.md) is there to help if you get stuck. {% callout() %} -When working on the engine's code, it's a good idea to introduce yourself in the `#engine-dev` channel on [Discord] and tell people about your plans. Communicating your progress early and often can help you avoid avoid headaches and disagreements during code review. - -[Discord]: https://discord.gg/bevy +When working on the engine's code, it's a good idea to introduce yourself in the `#engine-dev` channel on [Discord](https://discord.gg/bevy) and tell people about your plans. Communicating your progress early and often can help you avoid headaches and disagreements during code review. {% end %} ## Writing docs and examples -Bevy relies heavily on Rust's inline documentation and a collection of up-to-date examples, but both are in constant need of revision and improvement. If you'd like to help us improve our learning materials, take a look at the dedicated sections on [Writing Docs](TODO) and [Creating Examples](TODO). +Bevy relies heavily on Rust's inline documentation and a collection of up-to-date examples, but both are in constant need of revision and improvement. If you'd like to help us improve our learning materials, take a look at the dedicated sections on [Writing Docs](@/learn/contribute/helping-out/writing-docs.md) and [Creating Examples](@/learn/contribute/helping-out/creating-examples.md). ## Expanding the Ecosystem @@ -79,14 +77,14 @@ Check out our [plugin guidelines](@/learn/quick-start/plugin-development.md) for ## Organizing Issues and Pull Requests -If nothing brings you more satisfaction than seeing every last issue labeled and all resolved issues closed, feel free to hop on [Discord] and ask `@Maintainer` to be added to the Github organization. Anyone interested in helping us keep things neat and tidy is welcome to join. As will be discussed later, this role only requires good faith, a basic understanding of our development process, and a few merged pull requests. +If nothing brings you more satisfaction than seeing every last issue labeled and all resolved issues closed, feel free to hop on [Discord] and ping `@Maintainer` to be added to the GitHub organization. Anyone interested in helping us keep things neat and tidy is welcome to join. As will be discussed later, this role only requires good faith, a basic understanding of our development process, and a few merged pull requests. ## Teaching Others -Bevy is still very young, and it's light on documentation, tutorials, and accumulated expertise. By helping others with their issues and teaching them about Bevy, you will naturally learn the engine and codebase in greater depth (while also making our community better)! +Bevy is still relatively young, and it's light on documentation, tutorials, and accumulated expertise. By helping others with their issues and teaching them about Bevy, you will naturally learn the engine and codebase in greater depth (while also making our community better)! Some of the best ways to do this are: -- Answering questions on [Github Discussions], [Discord], and [Reddit](https://www.reddit.com/r/bevy). +- Answering questions on [GitHub Discussions], [Discord], and [Reddit](https://www.reddit.com/r/bevy). - Writing tutorials, guides, and other informal documentation and sharing them on [Bevy Assets](https://github.com/bevyengine/bevy-assets). - Streaming, writing blog posts, and creating videos. Share these in the `#devlogs` channel on [Discord]! diff --git a/content/contributing/helping-out/opening-pull-requests.md b/content/learn/contribute/helping-out/opening-pull-requests.md similarity index 66% rename from content/contributing/helping-out/opening-pull-requests.md rename to content/learn/contribute/helping-out/opening-pull-requests.md index 849e46989b..7a45f7f056 100644 --- a/content/contributing/helping-out/opening-pull-requests.md +++ b/content/learn/contribute/helping-out/opening-pull-requests.md @@ -13,10 +13,10 @@ Most changes don't require much "process". If your change is relatively straight * [GitHub Discussions]: An informal discussion with the community. This is the place to start if you want to propose a feature or specific implementation. * [Issue](https://github.com/bevyengine/bevy/issues): A formal way for us to track a bug or feature. Please look for duplicates before opening a new issue and consider starting with a Discussion. * [Pull Request](https://github.com/bevyengine/bevy/pulls) (or PR for short): A request to merge code changes. This starts our "review process". You are welcome to start with a pull request, but consider starting with an Issue or Discussion for larger changes (or if you aren't certain about a design). We don't want anyone to waste their time on code that didn't have a chance to be merged! But conversely, sometimes PRs are the most efficient way to propose a change. Use your own judgment here. -2. Other community members review and comment in an ad-hoc fashion. Active subject matter experts may be pulled into a thread using `@mentions`. If your PR has been quiet for a while and is ready for review, feel free to leave a message to "bump" the thread, or bring it up on [Discord] in an appropriate engine development channel. +2. Other community members review and comment in an ad-hoc fashion. Active Subject Matter Experts may be pulled into a thread using `@mentions`. If your PR has been quiet for a while and is ready for review, feel free to leave a message to "bump" the thread, or bring it up on [Discord] in an appropriate engine development channel. 3. Once they're content with the pull request (design, code quality, documentation, tests), individual reviewers leave "Approved" reviews. -4. After consensus has been reached (typically two approvals from the community or one for extremely simple changes) and CI passes, the [S-Ready-For-Final-Review](https://github.com/bevyengine/bevy/issues?q=is%3Aopen+is%3Aissue+label%3AS-Ready-For-Final-Review) label is added. -5. When they find time, someone with merge rights performs a final code review and queues the PR for merging. +4. After consensus has been reached (see [Reviewing Pull Requests](@/learn/contribute/helping-out/reviewing-pull-requests.md#how-pull-requests-are-merged) for more on that) and CI passes, the [S-Ready-For-Final-Review](https://github.com/bevyengine/bevy/issues?q=is%3Aopen+is%3Aissue+label%3AS-Ready-For-Final-Review) label is added. +5. When they find time, the Project Lead or a Maintainer performs a final code review and queues the PR for merging. [Discord]: https://discord.com/invite/bevy [GitHub Discussions]: https://github.com/bevyengine/bevy/discussions @@ -42,7 +42,10 @@ If you're new to Bevy, here's the workflow we use: recommendations to [compile with performance optimizations](https://bevyengine.org/learn/quick-start/getting-started/setup/#compile-with-performance-optimizations). 2. Make your changes in a local clone of your fork, typically in its own new branch. 1. Try to split your work into separate commits, each with a distinct purpose. Be particularly mindful of this when responding to reviews so it's easy to see what's changed. - 2. Tip: [You can set up a global `.gitignore` file](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer) to exclude your operating system/text editor's special/temporary files. (e.g. `.DS_Store`, `thumbs.db`, `*~`, `*.swp` or `*.swo`) This allows us to keep the `.gitignore` file in the repo uncluttered. + 2. {% callout() %} + Tip: [You can set up a global `.gitignore` file](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer) to exclude your operating system/text editor's special/temporary files. (e.g. `.DS_Store`, `thumbs.db`, `*~`, `*.swp` or `*.swo`) This allows us to keep the `.gitignore` file in the repository uncluttered. + {% end %} + 3. To test CI validations locally, run the `cargo run -p ci` command. This will run most checks that happen in CI, but can take some time. You can also run sub-commands to iterate faster depending on what you're contributing: * `cargo run -p ci -- lints` - to run formatting and Clippy. * `cargo run -p ci -- test` - to run tests. @@ -53,17 +56,17 @@ If you're new to Bevy, here's the workflow we use: To locally lint your files using the same workflow as our CI: 1. Install [markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli). 2. Run `markdownlint -f -c .github/linters/.markdown-lint.yml .` in the root directory of the Bevy project. -5. When working with Toml (`.toml`) files, Bevy's CI will check toml files using [taplo](https://taplo.tamasfe.dev/): `taplo fmt --check --diff` - 1. If you use VSCode, install [Even better toml](https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml) and format your files. +5. When working with TOML (`.toml`) files, Bevy's CI will check them for style and correctness using [taplo](https://taplo.tamasfe.dev/): `taplo fmt --check --diff` + 1. If you use VSCode, install [Even Better TOML](https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml) and format your files. 2. If you want to use the CLI tool, install [taplo-cli](https://taplo.tamasfe.dev/cli/installation/cargo.html) and run `taplo fmt --check --diff` to check for the formatting. Fix any issues by running `taplo fmt` in the root directory of the Bevy project. 6. Check for typos. Bevy's CI will check for them using [typos](https://github.com/crate-ci/typos). 1. If you use VSCode, install [Typos Spell Checker](https://marketplace.visualstudio.com/items?itemName=tekumara.typos-vscode). 2. You can also use the CLI tool by installing [typos-cli](https://github.com/crate-ci/typos?tab=readme-ov-file#install) and running `typos` to check for typos, and fix them by running `typos -w`. 7. Push your changes to your fork on GitHub and open a Pull Request. -8. Respond to any CI failures or review feedback. While CI failures must be fixed before we can merge your PR, you do not need to *agree* with all feedback from your reviews, merely acknowledge that it was given. If you cannot come to an agreement, leave the thread open and defer to a Maintainer or Project Lead's final judgement. -9. When your PR is ready to merge, a Maintainer or Project Lead will review it and suggest final changes. If those changes are minimal they may even apply them directly to speed up merging. +8. Respond to any CI failures or review feedback. While CI failures must be fixed before we can merge your PR, you do not need to *agree* with all feedback from your reviews, merely acknowledge that it was given. If you cannot come to an agreement, leave the thread open and defer to a Maintainer or the Project Lead's final judgement. +9. When your PR is ready to merge, a Maintainer or the Project Lead will review it and suggest final changes. If those changes are minimal they may even apply them directly to speed up merging. -If you end up adding a new official Bevy crate to the `bevy` repo: +If you end up adding a new official Bevy crate to the `bevy` repository: 1. Add the new crate to the [tools/publish.sh](https://github.com/bevyengine/bevy/blob/main/tools/publish.sh) file. 2. Check if a new cargo feature was added, update [docs/cargo_features.md](https://github.com/bevyengine/bevy/blob/main/docs/cargo_features.md) as needed. @@ -73,7 +76,7 @@ When contributing, please: * Prefer small PRs that incrementally improve things. * Explain what you're doing and why. * Try to loosely follow the workflow in [*Making changes to Bevy*](#making-changes-to-bevy). -* Consult the [style guide](@/contributing/helping-out/creating-examples.md#style-guide) to help keep our code base tidy. +* Consult the [style guide](@/learn/contribute/helping-out/opening-pull-requests.md#style-guide) to help keep our code base tidy. * Document new code with doc comments. * Include clear, simple tests. * Add or improve the examples when adding new user-facing functionality. @@ -84,6 +87,42 @@ Your first PR will be merged in no time! No matter how you're helping, thanks for contributing to Bevy! +## Style Guide + +### General guidelines + +1. Prefer granular imports over glob imports like `bevy_ecs::prelude::*`. +2. Use a consistent comment style: + 1. `///` doc comments belong above `#[derive(Trait)]` invocations. + 2. `//` comments should generally go above the line in question, rather than in-line. + 3. Avoid `/* */` block comments, even when writing long comments. + 4. Use \`variable_name\` code blocks in comments to signify that you're referring to specific types and variables. + 5. Start comments with capital letters. End them with a period if they are sentence-like. +3. Use comments to organize long and complex stretches of code that can't sensibly be refactored into separate functions. +4. When using [Bevy error codes](https://bevyengine.org/learn/errors/) include a link to the relevant error on the Bevy website in the returned error message `... See: https://bevyengine.org/learn/errors/b0003`. + +### Rust API guidelines + +As a reference for our API development we are using the [Rust API guidelines][Rust API guidelines]. Generally, these should be followed, except for the following areas of disagreement: + +#### Areas of disagreements + +Some areas mentioned in the [Rust API guidelines][Rust API guidelines] we do not agree with. These areas will be expanded whenever we find something else we do not agree with, so be sure to check these from time to time. + +> All items have a rustdoc example + +- This guideline is too strong and not applicable for everything inside of the Bevy game engine. For functionality that requires more context or needs a more interactive demonstration (such as rendering or input features), make use of the `examples` folder instead. + +> Examples use ?, not try!, not unwrap + +- This guideline is usually reasonable, but not always required. + +> Only smart pointers implement Deref and DerefMut + +- Generally a good rule of thumb, but we're probably going to deliberately violate this for single-element wrapper types like `Life(u32)`. The behavior is still predictable and it significantly improves ergonomics / new user comprehension. + +[Rust API guidelines]: https://rust-lang.github.io/api-guidelines/about.html + ## Receiving and Responding To Reviews Once you have opened your PR, your next task will be to shepherd it through community review so that it can be merged. Ideally it shouldn't be too long before a member of the community reviews your work, but sometimes PRs fall through the cracks. If your PR ends up sitting around for a few weeks with no interest, then don't be afraid to solicit reviews on the [Discord]. @@ -97,7 +136,10 @@ This is a natural part of any open source project. To avoid blocking these efforts, these pull requests may be *adopted*, where another contributor creates a new pull request with the same content. If there is an old pull request that is without updates, comment to the organization whether it is appropriate to add the *[S-Adopt-Me](https://github.com/bevyengine/bevy/labels/S-Adopt-Me)* label, to indicate that it can be *adopted*. -If you plan on adopting a PR yourself, you can also leave a comment on the PR asking the author if they plan on returning. +*S-Adopt-Me* PRs should be closed, and a tracking issue opened with the same labels to track their adoptions. + +If you plan on adopting a PR yourself, mention so in the tracking issue. +For a PR that hasn't been yet marked as open for adoption, you can also leave a comment on the PR asking the author if they plan on returning. If the author gives permission or simply doesn't respond after a few days, then it can be adopted. This may sometimes even skip the labeling process since at that point the PR has been adopted by you. @@ -107,3 +149,9 @@ When the new pull request is ready, it should reference the original PR in the d Then, notify org members to close the original. * For example, you can reference the original PR by adding the following to your PR description: `Adopted #number-original-pull-request` + +## Helping a PR get ready + +Without going to the complete adoption of a PR, sometimes the author needs help to get it approved or passing CI. +Those PRs can be labeled as *[S-Needs-Help](https://github.com/bevyengine/bevy/labels/S-Needs-Help)*, and opening PRs on them is welcomed to fix the last few points, resolve conflicts to pass CI. +You will need to work closely with the original author or one of the maintainer to add your commits to the original PR. diff --git a/content/contributing/helping-out/reporting-issues.md b/content/learn/contribute/helping-out/reporting-issues.md similarity index 69% rename from content/contributing/helping-out/reporting-issues.md rename to content/learn/contribute/helping-out/reporting-issues.md index d81e99c2b7..3f3317ffaa 100644 --- a/content/contributing/helping-out/reporting-issues.md +++ b/content/learn/contribute/helping-out/reporting-issues.md @@ -5,9 +5,9 @@ insert_anchor_links = "right" weight = 2 +++ -Bevy tracks bugs and feature requests using [Github Issues], which is an issue tracker and discussion space. You can find Bevy's issue page [here](https://github.com/bevyengine/bevy/issues), where you can navigate, filter, and view individual issues. +Bevy tracks bugs and feature requests using [GitHub Issues], which is an issue tracker and discussion space. You can find Bevy's issue page [here](https://github.com/bevyengine/bevy/issues), and Bevy's website's issue page [here](https://github.com/bevyengine/bevy-website/issues), where you can navigate, filter, and view individual issues. -[Github Issues]: https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues +[GitHub Issues]: https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues ## When to File an Issue @@ -16,21 +16,21 @@ Issues are great for formally tracking the progress of bugs and features. Here a - You want to receive feedback and ideas before writing code for Bevy. - You are not sure what is causing a bug, or how to fix it. - You do not have the capacity to work on the change, but want to make it known to others. -- The change may be controversial, and needs input from Subject Matter Experts and / or maintainers before going forward. +- The change may be controversial, and needs input from Subject Matter Experts and / or Maintainers before going forward. - You want to track a collection of features in a singular place. - This is known as a tracking issue, and has a dedicated label just for it! When in doubt, prefer creating an issue over immediately opening a pull request. This allows community members to weigh in before you spend time on work that may be unnecessary. -Before submitting an issue, please check that it has not already been created. [Github Search] is fairly good at finding similar issues based on keywords. If you do find an existing issue, please comment on it instead of creating a duplicate. +Before submitting an issue, please check that it has not already been created. [GitHub Search] is fairly good at finding similar issues based on keywords. If you do find an existing issue, please comment on it instead of creating a duplicate. -[Github Search]: https://github.com/search?q=repo%3Abevyengine%2Fbevy&type=issues +[GitHub Search]: https://github.com/search?q=repo%3Abevyengine%2Fbevy&type=issues ## When to Create a Discussion Instead -The Bevy repository also has [Github Discussions] enabled. Here are some scenarios where you may want to create a discussion post instead of an issue: +The Bevy repository also has [GitHub Discussions] enabled. Here are some scenarios where you may want to create a discussion post instead of an issue: -[Github Discussions]: https://github.com/bevyengine/bevy/discussions +[GitHub Discussions]: https://github.com/bevyengine/bevy/discussions - You have a question about using Bevy. - You have an idea on how to improve Bevy. diff --git a/content/contributing/helping-out/reviewing-pull-requests.md b/content/learn/contribute/helping-out/reviewing-pull-requests.md similarity index 64% rename from content/contributing/helping-out/reviewing-pull-requests.md rename to content/learn/contribute/helping-out/reviewing-pull-requests.md index d316f613a8..a4abc55d55 100644 --- a/content/contributing/helping-out/reviewing-pull-requests.md +++ b/content/learn/contribute/helping-out/reviewing-pull-requests.md @@ -23,9 +23,9 @@ If you're new to GitHub, there's a lot of great information on the official [Pul Focus on giving constructive, actionable feedback that results in real improvements to code quality or end-user experience. If you don't understand why an approach was taken, please ask! -Provide actual code suggestions when that is helpful. Small changes work well as comments or in-line suggestions on specific lines of codes. Larger changes deserve a comment in the main thread, or a pull request to the original author's branch (but please mention that you've made one). When in doubt about a matter of architectural philosophy, please refer back to [What we're trying to build](@/contributing/introduction.md#what-we-re-trying-to-build) for guidance. +Provide actual code suggestions when that is helpful. Small changes work well as comments or in-line suggestions on specific lines of codes. Larger changes deserve a comment in the main thread, or a pull request to the original author's branch (but please mention that you've made one). When in doubt about a matter of architectural philosophy, please refer back to our page on [What We're Trying to Build](@/learn/contribute/introduction.md#what-we-re-trying-to-build) for guidance. -It's okay to leave an approval even if you aren't 100% confident on all areas of the PR: just be sure to note your limitations. When maintainers are evaluating the PR to be merged, they'll make sure that there's good coverage on all of the critical areas. If you can only check that the math is correct, and another reviewer can check everything but the math, we're in good shape! +It's okay to leave an approval even if you aren't one-hundred percent confident on all areas of the PR, but just be sure to note your limitations. When Maintainers are evaluating the PR to be merged, they'll make sure that there's good coverage on all of the critical areas. If you can only check that the math is correct, and another reviewer can check everything but the math, we're in good shape! Similarly, if there are areas that would be good to fix, but aren't severe, please consider leaving an approval. The author can address them immediately, or spin it out into follow-up issues or PRs. Large PRs are much more draining for both reviewers and authors, so try to push for a smaller scope with clearly tracked follow-ups. @@ -42,19 +42,34 @@ Otherwise, please try to avoid asking for additional work unless absolutely nece With the large number of contributors and reviewers collectively building a complex system, disagreements will inevitably occur. Regardless of whether the disagreement is about naming, performance, or code coverage, the goal should be to reach a compromise amicably. - **Keep scope in mind**. Trivial cleanup of surrounding area is okay to recommend, but don't expect a contributor to overhaul a portion of Bevy on their own. -- **Don't be afraid to escalate**. Regardless of what side of the review process you're on, if you feel someone is being unreasonable don't hesitate to tag one of the maintainers or post in a related dev channel in the Discord. +- **Don't be afraid to escalate**. Regardless of what side of the review process you're on, if you feel someone is being unreasonable don't hesitate to tag one of the Maintainers or post in a related dev channel in the Discord. - **Not all review comments will necessarily be addressed**, and that's okay. Feel free to open an issue for further discussion. ## What to review There are three main places you can check for things to review: -1. Pull requests which are ready and in need of more reviews on [bevy](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+-label%3AS-Ready-For-Final-Review+-draft%3A%3Atrue+-label%3AS-Needs-RFC+-reviewed-by%3A%40me+-author%3A%40me). -2. Pull requests on [bevy](https://github.com/bevyengine/bevy/pulls) and the [bevy-website](https://github.com/bevyengine/bevy-website/pulls) repos. +1. Pull requests which are ready and in need of more reviews on the [`bevy` repository](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+-label%3AS-Ready-For-Final-Review+-draft%3A%3Atrue+-label%3AS-Needs-RFC+-reviewed-by%3A%40me+-author%3A%40me). +2. Pull requests on the [`bevy`](https://github.com/bevyengine/bevy/pulls) and the [`bevy-website`](https://github.com/bevyengine/bevy-website/pulls) repositories. 3. [RFCs](https://github.com/bevyengine/rfcs), which need extensive thoughtful community input on their design. -Not even our Project Leads and Maintainers are exempt from reviews and RFCs! By giving feedback on this work (and related supporting work), you can help us make sure our releases are both high-quality and timely. +Not even our Project Lead and Maintainers are exempt from reviews and RFCs! By giving feedback on this work (and related supporting work), you can help us make sure our releases are both high-quality and timely. -Finally, if nothing brings you more satisfaction than seeing every last issue labeled and all resolved issues closed, feel free to message @alice-i-cecile or @cart for a Bevy org role to help us keep things tidy. +Finally, if nothing brings you more satisfaction than seeing every last issue labeled and all resolved issues closed, feel free to message @alice-i-cecile or @cart for a Bevy Org role to help us keep things tidy. + +As discussed in our page on [The Bevy Organization](@/learn/contribute/project-information/bevy-organization.md), this role only requires good faith and a basic understanding of our development process. + +## How Pull Requests are merged + + +Maintainers abide by the following rules when merging pull requests: + +1. Trivial PRs can be merged with approval from one community member (including Maintainers). +2. Relatively uncontroversial PRs can be merged following approval from at least two community members (including Maintainers) with appropriate expertise. +3. Controversial PRs cannot be merged unless they have the approval of the Project Lead or two Subject Matter Experts (in the "area" of the PR). +4. If two Maintainers have approved a controversial PR they can "start the clock" on a PR by adding it to [this queue](https://github.com/orgs/bevyengine/projects/6). If 45 days elapse without SME or Project Lead action (approval, feedback or an explicit request to defer), the PR can be merged by maintainers. + +{% callout() %} +To read more on Maintainers, check out our section on them in our [The Bevy Organization](@/learn/contribute/project-information/bevy-organization.md#maintainer) page. +{% end %} -As discussed in our [Bevy Organization doc](TODO), this role only requires good faith and a basic understanding of our development process. diff --git a/content/contributing/helping-out/writing-docs.md b/content/learn/contribute/helping-out/writing-docs.md similarity index 84% rename from content/contributing/helping-out/writing-docs.md rename to content/learn/contribute/helping-out/writing-docs.md index c7bf98a6fe..3d883349e0 100644 --- a/content/contributing/helping-out/writing-docs.md +++ b/content/learn/contribute/helping-out/writing-docs.md @@ -8,7 +8,7 @@ weight = 5 Like every other large, rapidly developing open source library you've ever used, Bevy's documentation can always use improvement. This is incredibly valuable, and easily distributed, work that requires a bit of guidance: -* Inaccurate documentation is worse than no documentation: prioritize fixing broken docs. +* Inaccurate documentation is worse than no documentation; prioritize fixing broken docs. * Bevy is remarkably unstable; before tackling a new major documentation project, check in with the community on Discord or GitHub (making an issue about specific missing docs is a great way to plan) about the stability of that feature and upcoming plans to save yourself heartache. * Code documentation (doc examples and in the examples folder) is easier to maintain because the compiler will tell us when it breaks. * Inline documentation should be technical and to the point. Link relevant examples or other explanations if broader context is useful. @@ -17,14 +17,14 @@ This is incredibly valuable, and easily distributed, work that requires a bit of ## Documentation Sources -There are two main places where we keep docs: inline docs alongside the codebase, and on the Bevy website. +There are two main places where we keep docs: inline docs alongside the codebase, and on Bevy's website. ### Inline Docs The inline docs for each release are published to [docs.rs](https://docs.rs/bevy). To view the current docs on `main` before you contribute, you can go to [dev-docs.bevyengine.org](https://dev-docs.bevyengine.org/), -which has the latest API reference built from the repo on every commit made to the `main` branch. +which has the latest API reference built from the repository on every commit made to the `main` branch. To check out any local changes you've made: @@ -47,8 +47,8 @@ We also consider [bevyengine.org](https://bevyengine.org) to be part of our core To check out any local changes you've made: -1. [Download Zola v0.18.0](https://www.getzola.org/). -2. Clone the Bevy Website GitHub repository and enter that directory: +1. [Download Zola v0.19.2](https://www.getzola.org/). +2. Clone Bevy's website GitHub repository and enter that directory: 1. `git clone https://github.com/bevyengine/bevy-website.git` 2. `cd bevy-website` 3. Start the Zola server with `zola serve`. @@ -138,7 +138,7 @@ Users following the definition-first path will tend to take the following route: 6. As they explore, they will also browse: 1. The source code. 2. [docs.rs](https://docs.rs/bevy/) - 3. `CONTRIBUTING.md`, GitHub issues, and pull requests. + 3. The Contributing Guide, GitHub issues, and pull requests. 4. Release notes. 5. The engine development channels on Discord. 6. Advanced examples to see how everything comes together. @@ -166,7 +166,7 @@ This path should prioritize: ## Contributor's style guide -When writing and reviewing learning material for the Bevy Book and Quick Start Games, please try to follow these guidelines: +When writing and reviewing content for The Bevy Book, The Quick Start Guide, and other related learning materials, please try to follow these guidelines: ### Writing @@ -187,9 +187,9 @@ When writing and reviewing learning material for the Bevy Book and Quick Start G ### Organizational -1. Carefully organize your work into separate pages, headings, paragraphs and code blocks. +1. Carefully organize your work into separate pages, headings, paragraphs, and code blocks. 2. Clearly signal when you are explaining a concept in technical depth so it can be skipped. -3. Use lists, numbered lists and sub-lists to present information in bite-sized ways. +3. Use lists, numbered lists, and sub-lists to present information in bite-sized ways. 1. Refer back to these items by number! 4. Provide plenty of links, but be sure that what you are linking to is obvious by context. 1. Link to other sections of the book / example / web page when you mention them. @@ -209,28 +209,32 @@ When writing and reviewing learning material for the Bevy Book and Quick Start G 3. Lack of polish should serve an end: don't show bad or sloppy practices without a good reason. 4. Showing how (and why!) to refactor your code is a very powerful teaching tool. 6. Stick to a consistent style (e.g. for loops vs map) within each example. -7. If you need to give advice that will only matter to some of your audience (e.g. how to handle an edge case, or support a specific platform), do so in a clearly marked aside or list. +7. If you need to give advice that will only matter to some of your audience (e.g. how to handle an edge case, or support a specific platform), do so in a clearly marked aside (like a callout) or list. 8. Examples should not use or rely on third-party plugins. These may be appropriate to link in "next steps" however at the end of the examples. 1. Third-party crates should be limited to the most essential, such as `rand`. -9. If additional code block attributes like `no_run` or `hide-lines=x-y` need to be specified, you should always order these so that the language is the last attribute. If we would specify `rust,no_run` the syntax highlighting wouldn't work, but changing it to `no_run,rust` makes it work. -10. To validate local code changes you can either `./learning-code-examples/validate_examples.sh` from anywhere, or from the project's root `cd learning-code-examples && cargo check --examples && cargo clippy --examples && cargo fmt --check`. -11. To make sure your web-based files (html, markdown) are formatted correctly run the commands: - +9. To validate local code changes you can either `./learning-code-examples/validate_examples.sh` from anywhere, or from the project's root `cd learning-code-examples && cargo check --examples && cargo clippy --examples && cargo fmt --check`. +10. To make sure your web-based files (html, markdown) are formatted correctly run the commands: + ```sh markdownlint -f -c .github/linters/.markdown-lint.yml . djlint typos ``` - - in the root directory of your local Bevy website repository. This will format markdown files and tell you the issues in HTML files. In order to run the command you should install `markdownlint-cli`, `djlint`, and `typos-cli`. See: , , and . Note that the CI also includes `editorconfigchecker` but there isn't an easy way to run this manually, so you should instead rely on CI to validate files with this tool. -12. To reference Rust API docs you can use markdown's reference-style links like so: - [`HashMap`] - - ```md - [`HashMap`] - - [`HashMap`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html - ``` - - [`HashMap`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html + + in the root directory of your local Bevy's website's repository. + + This will format markdown files and tell you the issues in HTML files. In order to run the command you should install `markdownlint-cli`, `djlint`, and `typos-cli`. See for installation: , , and . + + {% callout() %} + The CI also includes `editorconfigchecker`, but there isn't an easy way to run this manually, so you should instead rely on CI to validate files with this tool. + {% end %} +11. To reference Rust API docs you can use markdown's reference-style links like so: [`HashMap`] + + ```md + [`HashMap`] + + [`HashMap`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html + ``` + + [`HashMap`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html diff --git a/content/contributing/introduction.md b/content/learn/contribute/introduction.md similarity index 80% rename from content/contributing/introduction.md rename to content/learn/contribute/introduction.md index d080a50c09..2ddc827bb4 100644 --- a/content/contributing/introduction.md +++ b/content/learn/contribute/introduction.md @@ -7,7 +7,7 @@ weight = 1 Hey, so you're interested in contributing to Bevy! Feel free to pitch in on whatever interests you and we'll be happy to help you contribute. -If you're new here, you should check out our community's [Code of Conduct]. You can also come say hi :wave: to us on [Discord]. It's a nice place to chat about Bevy development, ask questions, and get to know the other contributors and users in a less formal setting. +If you're new here, you should check out our community's [Code of Conduct]. You can also come say hi 👋 to us on [Discord]. It's a nice place to chat about Bevy development, ask questions, and get to know the other contributors and users in a less formal setting. [Code of Conduct]: https://github.com/bevyengine/bevy/blob/main/CODE_OF_CONDUCT.md [Discord]: https://discord.gg/bevy @@ -35,32 +35,33 @@ Bevy is a completely free and open source game engine built in Rust. It currentl Bevy also currently has the following "development process" goals: - **Rapid experimentation over API stability**: We need the freedom to experiment and iterate in order to build the best engine we can. This will change over time as APIs prove their staying power. -- **Consistent vision**: The engine needs to feel consistent and cohesive. This takes precedence over democratic and/or decentralized processes. See our [Bevy Organization doc] for more details. +- **Consistent vision**: The engine needs to feel consistent and cohesive. This takes precedence over democratic and/or decentralized processes. See our page on [The Bevy Organization] for more details. - **Flexibility over bureaucracy**: Developers should feel productive and unencumbered by development processes. - **Focus**: The Bevy Org should focus on building a small number of features excellently over merging every new community-contributed feature quickly. Sometimes this means pull requests will sit unmerged for a long time. This is the price of focus and we are willing to pay it. Fortunately Bevy is modular to its core. 3rd party plugins are a great way to work around this policy. - **User-facing API ergonomics come first**: Solid user experience should receive significant focus and investment. It should rarely be compromised in the interest of internal implementation details. - **Modularity over deep integration**: Individual crates and features should be "pluggable" whenever possible. Don't tie crates, features, or types together that don't need to be. -- **Don't merge everything... don't merge too early**: Every feature we add increases maintenance burden and compile times. Only merge features that are "generally" useful. Don't merge major changes or new features unless we have relative consensus that the design is correct *and* that we have the developer capacity to support it. When possible, make a 3rd party plugin / crate first, then consider merging once the API has been tested in the wild. Bevy's modular structure means that the only difference between "official engine features" and "third party plugins" is our endorsement and the repo the code lives in. We should take advantage of that whenever possible. +- **Don't merge everything... don't merge too early**: Every feature we add increases maintenance burden and compile times. Only merge features that are "generally" useful. Don't merge major changes or new features unless we have relative consensus that the design is correct *and* that we have the developer capacity to support it. When possible, make a 3rd party plugin / crate first, then consider merging once the API has been tested in the wild. Bevy's modular structure means that the only difference between "official engine features" and "third party plugins" is our endorsement and the repository the code lives in. We should take advantage of that whenever possible. - **Control and consistency over 3rd party code reuse**: Only add a dependency if it is *absolutely* necessary. Every dependency we add decreases our autonomy and consistency. Dependencies also have the potential to increase compile times and risk pulling in sub-dependencies we don't want / need. - **Don't re-invent every wheel**: As a counter to the previous point, don't re-invent everything at all costs. If there is a crate in the Rust ecosystem that is the "de-facto" standard (ex: `wgpu` or `winit`), we should heavily consider using it. Bevy should be a positive force in the ecosystem. We should drive the improvements we need into these core ecosystem crates. - **Rust-first**: Engine and user-facing code should optimize and encourage Rust-only workflows. Adding additional languages increases internal complexity, fractures the Bevy ecosystem, and makes it harder for users to understand the engine. Never compromise a Rust interface in the interest of compatibility with other languages. -- **Thoughtful public interfaces over maximal configurability**: Symbols and APIs should be private by default. Every public API should be thoughtfully and consistently designed. Don't expose unnecessary internal implementation details. Don't allow users to "shoot themselves in the foot". Favor one "happy path" API over multiple APIs for different use cases. +- **Thoughtful public interfaces over maximal configurability**: Symbols and APIs should be private by default. Every public API should be thoughtfully, and consistently, designed. Don't expose unnecessary internal implementation details. Don't allow users to "shoot themselves in the foot", instead favor one "happy path" API over multiple APIs for different use cases. - **Test what you need to**: Write useful tests. Don't write tests that aren't useful. We *generally* aren't strict about unit testing every line of code. We don't want you to waste your time. But at the same time: - Most new features should have at least one minimal [example](https://github.com/bevyengine/bevy/tree/main/examples). These also serve as simple integration tests, as they are run as part of our CI process. - - The more complex or "core" a feature is, the more strict we are about unit tests. Use your best judgement here. We will let you know if your pull request needs more tests. We use Rust's built in [testing framework]. + - The more complex, or "core", a feature is, the more strict we are about unit tests. Use your best judgement here, and we will let you know if your pull request needs more tests. + - We use Rust's built in [testing framework]. - **Welcome new contributors**: Invest in new contributors. Help them fill knowledge and skill gaps. Don't ever gatekeep Bevy development according to notions of required skills or credentials. Help new developers find their niche. -- **Civil discourse**: We need to collectively discuss ideas, and the best ideas *should* win, but conversations need to remain respectful at all times. Remember that we're all in this together and always follow our [Code of Conduct]. +- **Civil discourse**: We need to collectively discuss ideas, and the best ideas *should* win, but conversations need to remain respectful at all times. Remember that we're all in this together, and to always follow our [Code of Conduct]. -[Bevy Organization doc]: https://github.com/bevyengine/bevy/blob/main/docs/the_bevy_organization.md +[The Bevy Organization]: @/learn/contribute/project-information/bevy-organization.md [testing framework]: https://doc.rust-lang.org/book/ch11-01-writing-tests.html ## Getting Oriented -Bevy, like any general-purpose game engine, is a large project! It can be a bit overwhelming to start, so here's the bird's-eye view. +The Bevy Organization expands a little bit beyond just the Bevy engine, which by itself is a large project! It can be a bit overwhelming to start, so here's the bird's-eye view: -The [Github organization] has 2 primary repositories: +The [GitHub organization] has 2 primary repositories: -[Github organization]: https://github.com/bevyengine +[GitHub organization]: https://github.com/bevyengine 1. [`bevy`]: This is where the engine itself lives. The bulk of development work occurs here. 2. [`bevy-website`]: This is where the [official website] is hosted, along with the quick start, news, contributing book, live examples and other bits of polished content we want to show our users. @@ -75,4 +76,4 @@ These repositories are owned and managed by [The Bevy Foundation], a non-profit [The Bevy Foundation]: https://bevyengine.org/foundation/ {% end %} -The `bevy` repo itself contains many smaller subcrates. Several of them can be used by themselves and almost all of them can be modularly replaced. Feel free to dig around and find one that interests you! +The `bevy` repository itself contains many smaller subcrates. Several of them can be used by themselves and almost all of them can be modularly replaced. Feel free to dig around and find one that interests you! diff --git a/content/contributing/project-information/_index.md b/content/learn/contribute/project-information/_index.md similarity index 100% rename from content/contributing/project-information/_index.md rename to content/learn/contribute/project-information/_index.md diff --git a/content/contributing/project-information/bevy-organization.md b/content/learn/contribute/project-information/bevy-organization.md similarity index 67% rename from content/contributing/project-information/bevy-organization.md rename to content/learn/contribute/project-information/bevy-organization.md index 0c79c4eae6..7ea9cd6450 100644 --- a/content/contributing/project-information/bevy-organization.md +++ b/content/learn/contribute/project-information/bevy-organization.md @@ -5,10 +5,10 @@ insert_anchor_links = "right" weight = 2 +++ -The Bevy Organization is the group of people responsible for stewarding the Bevy Project. It handles things like merging pull requests, choosing project direction, managing bugs / issues / feature requests, running the Bevy website, controlling access to secrets, defining and enforcing best practices, etc. +The Bevy Organization is the group of people responsible for stewarding the Bevy Project. It handles things like merging pull requests, choosing project direction, managing bugs / issues / feature requests, running Bevy's website, controlling access to secrets, defining, and enforcing best practices, etc. {% callout(type="info") %} -Everyone is welcome and encouraged to contribute to Bevy, whether or not they're a Bevy Organization member. Community contributors (this means you) are encouraged to freely open issues, submit pull requests, and review pull requests. +Everyone is welcome, and encouraged, to contribute to Bevy, whether or not they're a Bevy Organization member. Community contributors (this means you) are encouraged to freely open issues, submit pull requests, and review pull requests. {% end %} The Bevy Organization is currently broken up into the following roles: @@ -17,21 +17,21 @@ The Bevy Organization is currently broken up into the following roles: The Project Lead has the final call on all design and code changes within Bevy. This is to ensure a coherent vision and consistent quality of code. They are responsible for representing the project publicly and interacting with other entities (companies, organizations, etc) on behalf of the project. They choose how the project is organized, which includes how responsibility is delegated. The role of Project Lead implicitly confers power of other roles (Maintainer, Subject Matter Expert, etc). -[Carter Anderson] (`@cart`) is, for now, our singular project lead. He tries to be accountable: open to new ideas and to changing his mind in the face of compelling arguments or community consensus. +[Carter Anderson] (`@cart`) is, for now, our singular project lead. He tries to be accountable, open to new ideas, and to changing his mind in the face of compelling arguments or community consensus. [Carter Anderson]: https://github.com/cart ## Maintainer -Maintainers have merge rights in Bevy repositories. They assess the scope of pull requests and whether they fit into the Bevy project's vision. They also serve as representatives of the Bevy Project and are often the interface between the Bevy community and the Bevy Project. They assist the Project Lead in moderating the community, handling administrative tasks, defining best practices, choosing project direction, and deciding how the project is organized. +Maintainers have merge rights in Bevy repositories. They assess the scope of pull requests and whether they fit into the Bevy Project's vision. They also serve as representatives of the Bevy Project and are often the interface between the Bevy community and the Bevy Project. They assist the Project Lead in moderating the community, handling administrative tasks, defining best practices, choosing project direction, and deciding how the project is organized. -Maintainers abide by the rules described in the section on [Using Github Issues](/B0rPTFF6TUyWrM1SwS7Cng) when merging pull requests. +Maintainers abide by the rules described in the section on [Reviewing Pull Requests](@/learn/contribute/helping-out/reviewing-pull-requests.md#how-pull-requests-are-merged) when merging pull requests. We choose new Maintainers carefully, and only after they have proven themselves in the Bevy community. Maintainers must have a proven track record of the following: 1. **A strong understanding of the Bevy Project as a whole**: our vision, our development process, and our community 2. **Solid technical skills and code contributions across most engine areas**: Maintainers must be able to evaluate the scope of pull requests, provide complete code reviews, ensure the appropriate people have signed off on a PR, and decide if changes align with our vision for Bevy. This can only be done if Maintainers are technical experts, both generically across engine subject areas, and more specifically in the Bevy codebase. -3. **Great social skills**: Maintainers regularly deal with and resolve "community issues" and serve as moderators on Discord. They must always present a professional and friendly face. They are representatives of the project and their actions directly reflect our goals and values. Working with them should not be painful. +3. **Great social skills**: Maintainers regularly deal with, and resolve, "community issues", and serve as moderators on Discord. They must always present a professional and friendly face. They are representatives of the project and their actions directly reflect our goals and values. Working with them should not be painful. 4. **Thorough reviews of other peoples' PRs**: Maintainers are the last line of defense when protecting project vision and code quality. They are also often the first people new contributors interact with. They must have a history of leaving thorough and helpful code reviews. 5. **Ethical and trustworthy behavior**: Maintainers are granted significant administrative permissions and serve as the board members of the Bevy Foundation. They must be trustworthy and professional. @@ -40,16 +40,18 @@ To make it easy to reach consensus, hold a high quality bar, and synchronize vis If you are interested in a Maintainer role and believe you meet these criteria, reach out to the Project Lead or one of our Maintainers. One month after every Bevy release Maintainers and the Project Lead will evaluate the need for new roles, review candidates, and vote. Bringing in a new Maintainer requires unanimous support from the Project Lead and all Maintainers. {% callout(type="info") %} -Check out the [Bevy People](https://bevyengine.org/community/people/#the-bevy-organization) page for the current list of Maintainerss. +Check out the [Bevy People](https://bevyengine.org/community/people/#the-bevy-organization) page for the current list of Maintainers. {% end %} ## Subject Matter Expert (SME) -Subject Matter Experts are members of the Bevy Organization that have proven themselves to be experts in a given development area (Rendering, Assets, ECS, UI, etc) and have a solid understanding of the Bevy Organization's vision for that area. They are great people to reach out to if you have questions about a given area of Bevy. +Subject Matter Experts are members of the Bevy Organization that have proven themselves to be experts in a given development area (Rendering, Assets, ECS, UI, etc), and have a solid understanding of the Bevy Organization's vision for that area. They are great people to reach out to if you have questions about a given area of Bevy. -SME approvals count as "votes" on controversial PRs (provided the PR is in their "subject area"). This includes [RFCs](https://github.com/bevyengine/rfcs) and working groups design documents. If a controversial PR has two votes from Subject Matter Experts in that PR's area, it can be merged without Project Lead approval. If a SME creates a PR in their subject area, this does count as a vote. However, the Project Lead has the right to revert changes merged this way, so it is each SME's responsibility to ensure they have synced up with the Project Lead's vision. Additionally, when approving a design, consensus between SMEs and the Project Lead (and ideally most of the wider Bevy community) is heavily encouraged. Merging without consensus risks fractured project vision and/or ping-ponging between designs. The "larger" the impact of a design, the more critical it is to establish consensus. +SME approvals count as "votes" on controversial PRs (provided the PR is in their "subject area"). This includes [RFCs](https://github.com/bevyengine/rfcs) and working groups design documents. If a controversial PR has two votes from Subject Matter Experts in that PR's area, it can be merged without Project Lead approval. If a SME creates a PR in their subject area, this does count as a vote. -We choose new SMEs carefully and only after they have proven themselves in the Bevy community. SMEs must have a proven track record of the following: +However, the Project Lead has the right to revert changes merged this way, so it is each SME's responsibility to ensure they have synced up with the Project Lead's vision. Additionally, when approving a design, consensus between SMEs and the Project Lead (and ideally most of the wider Bevy community) is heavily encouraged. Merging without consensus risks fractured project vision and/or ping-ponging between designs. The "larger" the impact of a design, the more critical it is to establish consensus. + +We choose new SMEs carefully, and only after they have proven themselves in the Bevy community. SMEs must have a proven track record of the following: 1. **Designing and contributing to foundational pieces in their subject area**: SMEs are responsible for building and extending the foundations of a given subject area. They must have a history of doing this before becoming an SME. 2. **Thorough reviews of other peoples' PRs in their subject area**: Within a subject area, SMEs are responsible for guiding people in the correct technical direction and only approving things aligned with that vision. They must have a history of doing this before becoming an SME. @@ -69,14 +71,22 @@ Check out the [Bevy People](https://bevyengine.org/community/people/#the-bevy-or 1. Have actively engaged with Bevy development. 2. Have demonstrated themselves to be polite and welcoming representatives of the project with an understanding of our goals and direction. -3. Have asked to join the Bevy Org. Reach out to the Maintainers on [Discord](https://discord.gg/bevy) or email us at if you are interested. +3. Have asked to join the Bevy Org. Reach out to the Maintainers on [Discord](https://discord.gg/bevy) or email us at if you are interested. If you've been around the community for a while, just ask! There are no formal responsibilities and this is intended to cover the community of people making Bevy quite broadly. -All Bevy Org members are also Triage Team members. The Triage Team can label and close issues and PRs but do not have merge rights or any special authority within the community. +All Bevy Org members are also Triage Team members. The Triage Team can label and close issues and PRs, but do not have merge rights or any special authority within the community. ## Role Rotation -All Bevy Organization roles (excluding the Triage Team) have the potential for "role rotation". Roles like Project Lead, Maintainer, and SME are intentionally kept in limited supply to ensure a cohesive project vision. However these roles can be taxing, and qualified motivated people deserve a chance to lead. To resolve these issues, we plan on building in "role rotation". What this looks like hasn't yet been determined (as this issue hasn't come up yet and we are still in the process of scaling out our team), but we will try to appropriately balance the needs and desires of both current and future leaders, while also ensuring consistent vision and continuity for Bevy. +All Bevy Organization roles, excluding the Triage Team, have the potential for "role rotation". + +Roles like Project Lead, Maintainer, and SME are intentionally kept in limited supply to ensure a cohesive project vision. However these roles can be taxing, and qualified motivated people deserve a chance to lead. + +To resolve these issues, we plan on building in "role rotation". What this looks like hasn't yet been determined (as this issue hasn't come up yet and we are still in the process of scaling out our team), but we will try to appropriately balance the needs and desires of both current and future leaders, while also ensuring consistent vision and continuity for Bevy. -Additionally, if you are currently holding a role that you can no longer "meaningfully engage with", please reach out to the Project Lead and Maintainers about rotating out. If you hold a role but don't engage with it, you are preventing other qualified people from driving the project forward. Note that leaving a role doesn't need to be permanent. If you need to rotate out because your life is currently busy with work / life / school / etc, but later you find more time, we can discuss rotating back in! +Additionally, if you are currently holding a role that you can no longer "meaningfully engage with", please reach out to the Project Lead and Maintainers about rotating out. If you hold a role but don't engage with it, you are preventing other qualified people from driving the project forward. + +{% callout() %} +Leaving a role doesn't need to be permanent. If you need to rotate out because your life is currently busy with work / life / school / etc, but later you find more time, we can discuss rotating back in! +{% end %} diff --git a/content/learn/contribute/project-information/release-process.md b/content/learn/contribute/project-information/release-process.md new file mode 100644 index 0000000000..88086d60c1 --- /dev/null +++ b/content/learn/contribute/project-information/release-process.md @@ -0,0 +1,177 @@ ++++ +title = "Release Process" +insert_anchor_links = "right" +[extra] +weight = 3 ++++ + +Bevy uses three-months-long development cycles, delimited by a weeks-long rolling release process. + +This means that Bevy releases a new version roughly once every three to four months. In an effort to avoid crunch and encourage sustainable development, we do not pick specific dates or deadlines. + +## Development Cycles + +During a three-month development cycle, Maintainers collect important PRs and issues into a GitHub Milestone. Issues included in the milestone are given priority, and the community generally makes a best-effort attempt to merge as many of these as possible over the duration of the cycle. + +In the lead-up to a release (generally about two and a half months after the previous) we begin to aggressively purge the milestone of things that seem unlikely to be ready in time. The main things that tend to remain are: + +- Quick and easy features under active development. +- Fixes for important regressions or crashes. +- Large or impressive features that only need minor polish. + +When the milestone is complete, we open a new working group to handle the release preparations, publish a release candidate (ex. `0.14.0-rc.1`) and begin the release process. + +## Release Candidates + +In the run-up to a release, Bevy publishes a new release candidate about once a week. Publishing release candidates allows users to identify bugs and regressions, gives ecosystem crates time to update so they can be ready closer to release day, and provides Bevy contributors extra time to write release notes and migration guides. + +When publishing a release candidate, we also announce a general target release date. This is generally about one week out. If critical bugs or regressions are discovered during this testing window, we fix them and publish a new release candidate. Then we either + +- Announce a new date, if we believe more testing time is needed than the current window, or +- Keep the same target release date if we believe there is enough time in the current window. + +When we successfully hit a release candidate's target date, we do the final release. + +## Release Checklist + +When making a release, the Maintainers follow these checklists: + +### Minor Version + +#### Minor Pre-release + +1. Check regressions tag. +2. Check appropriate milestone and close it. +3. Check GitHub Projects page for staleness. +4. Run the [`generate-release`](https://github.com/bevyengine/bevy-website/tree/main/generate-release) tool. + 1. Create migration guide. + 2. Write blog post. + 3. Generate contributors list + 4. Generate change log. +5. Update book. +6. Bump version number for all crates, using the "Release" workflow. + 1. Change the commit message to be nicer. +7. Create tag on GitHub. +8. Edit GitHub Release. Add links to the `Release announcement` and `Migration Guide`. +9. Bump `latest` tag to most recent release. +10. Run the [`update-screenshots` workflow] to update screenshots. *This will block blog post releases (and take ~40 minutes) so do it early*. +11. Run the [`build-wasm-examples` workflow] to update Wasm examples. + +#### Minor Release + +1. Release on crates.io using `bash tools/publish.sh` +2. Announce on: + 1. HackerNews + 2. Twitter + 3. Reddit: /r/bevy, /r/rust, /r/rust_gamedev + 4. Discord: Bevy, Game Development in Rust, Rust Programming Language Community + 5. This Month in Rust Game Development newsletter + 6. This Week in Rust newsletter + +#### Minor Post-release + +1. Bump version number for all crates to next versions, as `0.X-dev`, using the "Post-release version bump" workflow, to ensure properly displayed version for [Dev Docs](https://dev-docs.bevyengine.org/bevy/index.html). +2. Update Bevy version used for Bevy's website's `learning-code-examples` tool (code example validation and formatting for the learning materials) to latest release. + +### Patch + +#### Patch Pre-release + +1. Check appropriate milestone. +2. Close the milestone, open the next one if anything remains and transfer them. +3. Create a new branch `release-0.X.Y` from the `latest` tag, and cherry pick all PRs from the milestone to the new branch +```sh +version="0.X.Y" + +git checkout latest +git checkout -b release-$version +echo + +prs=`gh pr list --repo bevyengine/bevy --search "milestone:$version" --state merged --json mergeCommit,mergedAt,title,number --limit 100` +while read -r commit number title <&3; do + echo "PR #$number: $title (https://github.com/bevyengine/bevy/pull/$number)" + if git cherry-pick $commit; then + echo + else + echo "please resolve conflict then press enter" + read + fi +done 3<<(echo $prs | jq --raw-output '. |= sort_by(.mergedAt) | .[] | "\(.mergeCommit.oid) \(.number) \(.title)"') +``` +4. Bump version number for all crates, using [the command from the "Release" workflow] locally, with `patch` for the new version. + - Change the commit message to be nicer: `git commit --amend -m "Release 0.X.Y` +5. Create tag on GitHub. +6. Edit GitHub Release. Add link to the comparison between this patch and the previous version. +7. Bump `latest` tag to most recent release. +8. Run the [`update-screenshots` workflow] to update screenshots. +9. Run this [`build-wasm-examples` workflow] to update Wasm examples. + +#### Patch Release + +1. Release on crates.io + - `bash tools/publish.sh` +2. Announce on: + 1. Discord: Bevy, #announcements + +#### Patch Post-Release + +### Release Candidate + +#### RC Pre-Release + +1. Check appropriate milestone. +2. For the first RC, create a new branch `release-0.X.0` for the release from `main`. +3. For following RCs, cherry pick all merged PRs from the milestone that are not yet in the release branch +```sh +version="0.X" + +git checkout release-$version.0 + +# List the last 100 PRs merged in the milestone +prs=`gh pr list --repo bevyengine/bevy --search "milestone:$version" --state merged --json mergeCommit,mergedAt,title,number --limit 100` +while read -r commit number title <&3; do + # Ignore commits that are already present by sha + if git merge-base --is-ancestor $commit HEAD; then + continue + fi + # Ignore commits that are already present by PR number + if git log --format=oneline | grep " (#$number)$" > /dev/null; then + continue + fi + + echo "PR #$number: $title (https://github.com/bevyengine/bevy/pull/$number)" + if git cherry-pick $commit; then + echo + else + echo "please resolve conflict then press enter" + read + fi +done 3<<(echo $prs | jq --raw-output '. |= sort_by(.mergedAt) | .[] | "\(.mergeCommit.oid) \(.number) \(.title)"') +``` +4. Bump version number for all crates, using [the command from the "Release" workflow] locally, with `rc` for the new version. + - Change the commit message to be nicer: `git commit --amend -m "Release 0.X.0-rc.Y` +5. Create tag on GitHub. +6. Edit GitHub Release. Add link to the comparison between this release candidate (rc) and the previous version. + +#### RC Release + +1. Release on crates.io + - `bash tools/publish.sh` +2. Announce on: + 1. Discord: Bevy, #dev-announcements + +#### RC Post-Release + +1. Update Bevy version used for Bevy's website's `learning-code-examples` tool (code example validation and formatting for the learning materials) to latest release. +2. Check that docs.rs was able to build the documentation of all crates +```sh +version="0.X.0-rc.Y" +for crate in `cargo test -p 2>&1 | grep ' bevy'` +do + curl -s -i https://docs.rs/crate/$crate/$version | grep "failed to build" | grep $version +done +``` + +[`update-screenshots` workflow]: https://github.com/bevyengine/bevy-website/actions/workflows/update-screenshots.yml +[`build-wasm-examples` workflow]: https://github.com/bevyengine/bevy-website/actions/workflows/build-wasm-examples.yml +[the command from the "Release" workflow]: https://github.com/bevyengine/bevy/blob/main/.github/workflows/release.yml diff --git a/content/contributing/project-information/working-groups.md b/content/learn/contribute/project-information/working-groups.md similarity index 63% rename from content/contributing/project-information/working-groups.md rename to content/learn/contribute/project-information/working-groups.md index 7944f64b9f..672dd1fc0d 100644 --- a/content/contributing/project-information/working-groups.md +++ b/content/learn/contribute/project-information/working-groups.md @@ -7,33 +7,39 @@ weight = 1 Working groups are temporary community initiatives devoted to particularly complex, large, or important tasks. This might include: -- undertaking a major refactor -- adding an unusually complex new feature -- upstreaming an ecosystem crate -- preparing for a new release -- bootstrapping new major documentation efforts +- Undertaking a major refactor. +- Adding an unusually complex new feature. +- Upstreaming an ecosystem crate. +- Preparing for a new release. +- Bootstrapping new major documentation efforts. As you can see, these aren't purely for programming tasks! -Much of the difficulty, work and controversy involved in maintaining a major game engine centers around mundane or social tasks. -Coordinating efforts there is just as important! +Much of the difficulty, work, and controversy involved in maintaining a major game engine centers around mundane or social tasks. +Coordinating the efforts for those tasks can be just as important as coordinating the addition of a fancy new feature! {% callout(type="info") %} -You can read more about how to find and join active working groups in the [How You Can Help](todo) section. +You can read more about how to find, and join, active working groups in the [How You Can Help](@/learn/contribute/helping-out/how-you-can-help.md) section. {% end %} ## Ground Rules When participating in a working group, here are a few things to keep in mind: -- No one is in charge. The founders of a working group do not own it. -- These are social spaces. Everyone is invited, anyone can drop in to chat. +- No one is in charge in a working group; the founders of a working group do not own it. +- These are social spaces where anyone is invited and can drop in to chat. - Working groups are "hop-in hop-out". No commitments, minimal crunch, everyone contributes what they can when they can. -- The goal is consensus. Before going to the SMEs, try to come to a decision all the major stakeholders are content with. -- Communication is key. Having a group of people who are clued-in to the design process will let you sail through our review process. +- The decisions made in working groups should be uncontroversial among the group, commonly agreed upon by all major stakeholders, before going to the Subject Matter Expertss. +- Communication among the group is great, since a group of people who are clued-in to the design process will let you sail through our review process easier than you would otherwise. ## Life-Cycle of a Working Group -Working groups move through three loose phases: An initial proposal, a period of design and approval, and finally the bulk of the implementation work. These phases are intended to be lightweight, and are sometimes little more than a formality. +Working groups move through three loose phases: + +1. An initial proposal. +2. A period of design and approval. +3. And finally the bulk of the implementation work. + +These phases are intended to be lightweight, and are sometimes little more than a formality. ## Make A Proposal @@ -57,13 +63,13 @@ This is the primary review step: Maintainers and SMEs should be broadly patient ## Implement The Design Doc -With a sign-off in hand, post the design doc to [Github Discussions](https://github.com/Bevyengine/Bevy/discussions) with the [`C-Design-Doc` label](https://github.com/Bevyengine/Bevy/discussions?discussions_q=is%3Aopen+label%3A%22C-Design+Doc%22) for archival purposes and begin work on implementation. -Post PRs that you need review on in your group's forum thread, ask for advice, and share the load. -Controversial PRs are still `X-Controversial`, but with a sign-off-in-priniciple, things should go more smoothly. +With a sign-off in hand, post the design doc to [GitHub Discussions](https://github.com/Bevyengine/Bevy/discussions) with the [`C-Design-Doc` label](https://github.com/Bevyengine/Bevy/discussions?discussions_q=is%3Aopen+label%3A%22C-Design+Doc%22) for archival purposes and begin work on implementation. +Post PRs that you need reviews on in your group's forum thread, ask for advice, and share the load. +Controversial PRs are still `X-Controversial`, but with a sign-off-in-principle, things should go more smoothly. If work peters out and the initiative dies, Maintainers can wind down working groups (in consultation with SMEs and the working group itself). -This is normal and expected: projects fail for all sorts of reasons! -However, it's important to both keep the number of working groups relatively small and ensure they're active: +This is normal and expected— projects fail for all sorts of reasons! +However, it's important to both keep the number of working groups relatively small and ensure they're active, since they serve a vital role in onboarding new contributors. Once your implementation work laid out in your initial design doc is complete, it's time to wind down the working group. diff --git a/content/contributing/reference/_index.md b/content/learn/contribute/reference/_index.md similarity index 57% rename from content/contributing/reference/_index.md rename to content/learn/contribute/reference/_index.md index ac5bcaaaba..0af4eece25 100644 --- a/content/contributing/reference/_index.md +++ b/content/learn/contribute/reference/_index.md @@ -1,6 +1,7 @@ +++ title = "Reference" template = "docs.html" +redirect_to = "/learn/contribute/reference/triage" [extra] weight = 4 +++ diff --git a/content/contributing/reference/triage.md b/content/learn/contribute/reference/triage.md similarity index 71% rename from content/contributing/reference/triage.md rename to content/learn/contribute/reference/triage.md index 2d5939fee8..f07e8e4023 100644 --- a/content/contributing/reference/triage.md +++ b/content/learn/contribute/reference/triage.md @@ -9,7 +9,7 @@ Bevy's scope and user base means that it gets a large volume of issues and pull ## Classifying Issues and PRs -Labels are our primary tool for organizing work. You can find a complete list with descriptions [here](https://github.com/bevyengine/bevy/labels). These are a few of the most common, organized by category: +Labels are our primary tool for organizing work. You can find a complete list with descriptions [here](https://github.com/bevyengine/bevy/labels) for the engine, or [here](https://github.com/bevyengine/bevy-website/labels) for the website. These are a few of the most common, organized by category: - **A**: Area (e.g. `A-Animation`, `A-ECS`, `A-Rendering`, ...). - **C**: Category. The most common include: @@ -19,8 +19,6 @@ Labels are our primary tool for organizing work. You can find a complete list wi - `C-Code-Quality`: a section of code that is hard to understand or change. - `C-Performance`: a change motivated by speed, memory usage, or compile times. - `C-Tracking-Issue`: collects information on a broad development initiative. - - `C-Needs-Release-Notes`: work that should be called out in the blog post due to impact. This decision is usually made by maintainers, but feel free to nominate a change in the comments if you think it deserves the spotlight! - - `C-Breaking-Change`: a breaking change to Bevy's public API, and should be noted in the migration guide. - **D**: Difficulty. This can either be the estimated level of expertise (not time) to solve an issue or review a pull request. In order, these are: - `D-Trivial`: typos, obviously incorrect one-line bug fixes, code reorganization, and renames. - `D-Straightforward`: simple bug fixes, API improvements, docs, tests, and examples. @@ -33,20 +31,24 @@ Labels are our primary tool for organizing work. You can find a complete list wi - Most work is not explicitly categorized by priority; volunteer work mostly occurs on an ad hoc basis depending on contributor interests. - **S**: Status. The most common include: - `S-Needs-Triage`: this issue needs to be labeled. - - `S-Adopt-Me`: the original PR author has no intent to complete the PR, and it should be adopted by another contributor. + - `S-Adopt-Me`: the original PR author has no intent to complete the PR, and it should be adopted by another contributor. This PR should be closed, and have an issue linked to track its adoption. - `S-Blocked`: cannot move forward until something else changes. - `S-Needs-Review`: this PR needs reviewer attention to move forward. - `S-Waiting-On-Author`: the author needs to make changes to this PR before it can be approved. - - `S-Ready-For-Final-Review`: this PR has been approved by the community and is ready for a maintainer to consider merging it. + - `S-Ready-For-Final-Review`: this PR has been approved by the community and is ready for a Maintainer to consider merging it. + - `S-Needs-Help`: this PR is almost ready to be merged but blocked on a technical issue. Helping to fix it is welcomed. - **X**: Controversiality. In order, these are: - `X-Uncontroversial`: everyone should agree that this is a good idea. - `X-Contentious`: there's real design thought needed to ensure that this is the right path forward. - `X-Controversial`: there's active disagreement and / or large-scale architectural implications involved. - `X-Blessed`: work that was previously controversial, but whose controversial (but perhaps not technical) elements have been endorsed by the relevant decision makers. +- **M**: Meta, for supporting work that needs to be done. + - `M-Needs-Release-Note`: work that should be called out in the blog post due to impact. This decision is usually made by Maintainers, but feel free to nominate a change in the comments if you think it deserves the spotlight! + - `M-Needs-Migration-Guide`: this is a breaking change to Bevy's public API, and requires advice on how to migrate existing code. These changes cannot be shipped in minor versions! -You can learn more about labels on [Github's documentation](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels). +You can learn more about labels on [GitHub's documentation](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels). -The rules for how PRs get merged depend on their classification by controversy and difficulty. More difficult PRs will require more careful review from experts, while more controversial PRs will require rewrites to reduce the costs involved and / or sign-off from Subject Matter Experts and maintainers. +[The rules for how PRs get merged](@/learn/contribute/helping-out/reviewing-pull-requests.md#how-pull-requests-are-merged) depend on their classification by controversy and difficulty. More difficult PRs will require more careful review from experts, while more controversial PRs will require rewrites to reduce the costs involved and / or sign-off from Subject Matter Experts and Maintainers. When making PRs, try to split out more controversial changes from less controversial ones, in order to make your work easier to review and merge. Also consider splitting simple changes from complex ones, since the simple changes can be reviewed and merged much quicker. @@ -98,19 +100,20 @@ This might happen if: 3. The PR was successfully adopted. 4. The work is particularly low quality, and the author is resistant to coaching. 5. The work adds features or abstraction of limited value, especially in a way that could easily be recreated outside of the engine. -6. The work has been sitting in review for so long and accumulated so many conflicts that it would be simpler to redo it from scratch. +6. The work has been sitting in review for so long and accumulated so many conflicts that it needs substantial work to get it in a correct state. 7. The PR is pointlessly large, and should be broken into multiple smaller PRs for easier review. - -PRs that are `S-Adopt-Me` should be left open, but only if they're genuinely more useful to rebase rather than simply use as a reference. +8. The PR is controversial and hasn't seen activity in the last 6 months. There are several paths for PRs to be closed: 1. Authors may close their own PRs for any reason at any time. -2. If a PR is clearly spam or malicious, anyone with triage rights is encouraged to close out the PR and report it to Github. -3. If the work has already been done elsewhere, adopted or otherwise obsoleted, anyone with triage rights is encouraged to close out the PR with an explanatory comment. -4. Anyone may nominate a PR for closure, by bringing it to the attention of the author and / or one of the SMEs / maintainers. Let them press the button, but this is generally well-received and helpful. -5. SMEs or maintainers may and are encouraged to unilaterally close PRs that fall into one or more of the remaining categories. -6. In the case of PRs where some members of the community (other than the author) are in favor and some are opposed, any two relevant SMEs or maintainers may act in concert to close the PR. +2. If a PR is clearly spam or malicious, anyone with triage rights is encouraged to close out the PR and report it to GitHub. +3. If the work has already been done elsewhere, adopted, or otherwise obsoleted, anyone with triage rights is encouraged to close out the PR with an explanatory comment. +4. Anyone may nominate a PR for closure, by bringing it to the attention of the author and / or one of the SMEs / Maintainers. Let them press the button, but this is generally well-received and helpful. +5. SMEs or Maintainers may, and are encouraged, to unilaterally close PRs that fall into one or more of the remaining categories. +6. In the case of PRs where some members of the community, other than the author, are in favor, and some are opposed, any two relevant SMEs or Maintainers may act in concert to close the PR. +7. For a PR that has been sitting for a while and became bitrotten, check with the original author if they intend to continue working on it. If not, or without a response, the PR can be labeled with `S-Adopt-Me`, and closed. Tracking adoption progress will happen in a linked issue. +8. Inactive `X-Controversial` can be closed if relevant SMEs or Maintainers have decided there's no more interest for it. If it's still interesting and controversial, a decision must be made. When closing a PR, check if it has an issue linked. If it does not, you should strongly consider creating an issue and linking the now-closed PR to help make sure the previous work can be discovered and credited. @@ -121,6 +124,6 @@ Members of the Triage Team within the Bevy organization have permissions to labe 1. They have actively engaged with Bevy development in the past. 2. They have demonstrated themselves to be polite and welcoming representatives of the project with an understanding of its goals and direction. -If that applies to you, then feel free to ask a maintainer on [Discord] or email . Everyone is welcome to do this. We generally accept membership requests, so don't hesitate if you are interested! +If that applies to you, then feel free to ask a Maintainer on [Discord] or email . Everyone is welcome to do this. We generally accept membership requests, so don't hesitate if you are interested! [Discord]: https://discord.gg/bevy diff --git a/content/learn/links.toml b/content/learn/links.toml index f0dc4121b2..915d663548 100644 --- a/content/learn/links.toml +++ b/content/learn/links.toml @@ -19,6 +19,13 @@ image = "/assets/rust-logo-light.svg" image_alt = "Rust logo" description = "Learn how to use Bevy's types, traits and methods using the in-depth reference documentation, complete with inline examples." +[[links]] +title = "Contributing Guide" +url = "/learn/contribute/introduction" +image = "/assets/book.svg" +image_alt = "A slanted book" +description = "Learn how to best contribute to the Bevy Project." + [[links]] title = "Official Examples" url = "https://github.com/bevyengine/bevy/tree/latest/examples#examples" diff --git a/content/learn/migration-guides/0.10-to-0.11.md b/content/learn/migration-guides/0.10-to-0.11.md index 8d90ade691..59ee0cf065 100644 --- a/content/learn/migration-guides/0.10-to-0.11.md +++ b/content/learn/migration-guides/0.10-to-0.11.md @@ -9,7 +9,7 @@ weight = 6 Bevy relies heavily on improvements in the Rust language and compiler. As a result, the Minimum Supported Rust Version (MSRV) is "the latest stable release" of Rust. -
+
### [Schedule-First: the new and improved add_systems](https://github.com/bevyengine/bevy/pull/8079) diff --git a/content/learn/migration-guides/0.11-to-0.12.md b/content/learn/migration-guides/0.11-to-0.12.md index 01bc95e684..7f16155acc 100644 --- a/content/learn/migration-guides/0.11-to-0.12.md +++ b/content/learn/migration-guides/0.11-to-0.12.md @@ -9,7 +9,7 @@ weight = 7 Bevy relies heavily on improvements in the Rust language and compiler. As a result, the Minimum Supported Rust Version (MSRV) is "the latest stable release" of Rust. -
+
### [API updates to the AnimationPlayer](https://github.com/bevyengine/bevy/pull/9002) @@ -676,7 +676,7 @@ app.configure_schedules(build_settings);
App
-`Events::update_system` has been split off from the the type and can be found at `bevy_ecs::event::event_update_system`. +`Events::update_system` has been split off from the type and can be found at `bevy_ecs::event::event_update_system`. ### [Allow disjoint mutable world access via `EntityMut`](https://github.com/bevyengine/bevy/pull/9419) @@ -717,7 +717,7 @@ let scene = DynamicSceneBuilder::from_world(&world)
Input
-The default live zone bounds have been changed from `-0.95..=0.95` to `-1.0..=1.0` to align with more common usage. If you were relying on the old default, you can change change this by modifying [`GamepadSettings::default_axis_settings`](https://docs.rs/bevy/0.12.0/bevy/input/gamepad/struct.GamepadSettings.html#structfield.default_axis_settings). +The default live zone bounds have been changed from `-0.95..=0.95` to `-1.0..=1.0` to align with more common usage. If you were relying on the old default, you can change this by modifying [`GamepadSettings::default_axis_settings`](https://docs.rs/bevy/0.12.0/bevy/input/gamepad/struct.GamepadSettings.html#structfield.default_axis_settings). ### [Rename bevy_math::rects conversion methods](https://github.com/bevyengine/bevy/pull/9159) diff --git a/content/learn/migration-guides/0.12-to-0.13.md b/content/learn/migration-guides/0.12-to-0.13.md index a581642a8f..498592e584 100644 --- a/content/learn/migration-guides/0.12-to-0.13.md +++ b/content/learn/migration-guides/0.12-to-0.13.md @@ -8,7 +8,7 @@ long_title = "Migration Guide: 0.12 to 0.13" Bevy relies heavily on improvements in the Rust language and compiler. As a result, the Minimum Supported Rust Version (MSRV) is "the latest stable release" of Rust. -
+
### [Support all types of animation interpolation from gltf](https://github.com/bevyengine/bevy/pull/10755) diff --git a/content/learn/migration-guides/0.14-to-0.15.md b/content/learn/migration-guides/0.14-to-0.15.md new file mode 100644 index 0000000000..2aaa980076 --- /dev/null +++ b/content/learn/migration-guides/0.14-to-0.15.md @@ -0,0 +1,11 @@ ++++ +title = "0.14 to 0.15" +insert_anchor_links = "right" +[extra] +weight = 10 +long_title = "Migration Guide: 0.14 to 0.15" +public_draft = 1741 +status = 'hidden' ++++ + +{{ migration_guides(version="0.15") }} diff --git a/content/learn/migration-guides/0.6-to-0.7.md b/content/learn/migration-guides/0.6-to-0.7.md index 7a721f694c..fcde60fd50 100644 --- a/content/learn/migration-guides/0.6-to-0.7.md +++ b/content/learn/migration-guides/0.6-to-0.7.md @@ -7,7 +7,7 @@ long_title = "Migration Guide: 0.6 to 0.7" weight = 2 +++ - + ### [ParamSet for conflicting SystemParam](https://github.com/bevyengine/bevy/pull/2765) diff --git a/content/learn/migration-guides/0.7-to-0.8.md b/content/learn/migration-guides/0.7-to-0.8.md index 31b9077b40..0715337314 100644 --- a/content/learn/migration-guides/0.7-to-0.8.md +++ b/content/learn/migration-guides/0.7-to-0.8.md @@ -12,7 +12,7 @@ Before migrating make sure to run `rustup update` Bevy relies heavily on improvements in the Rust language and compiler. As a result, the Minimum Supported Rust Version (MSRV) is "the latest stable release" of Rust. - + ### [Camera Driven Rendering](https://github.com/bevyengine/bevy/pull/4745) @@ -356,7 +356,7 @@ Please [file an issue](https://github.com/bevyengine/bevy/issues) to help detail * a `HandleId`, use `&Handle::weak(id)` instead, to create a weak handle. You may have been able to store a type safe `Handle` instead. * a `HandleUntyped`, use `&handle_untyped.typed_weak()` to create a weak handle of the specified type. This is most likely to be the useful when using [load_folder](https://docs.rs/bevy_asset/latest/bevy_asset/struct.AssetServer.html#method.load_folder) * a `&str` or anything not previously mentioned: `assets.get(&assets.get_handle("asset/path.ron"))` -* a `Handle` of of a different type, consider whether this is the correct handle type to store. If it is (i.e. the same handle id is used for multiple different Asset types) use `Handle::weak(handle.id)` to cast to a different type. +* a `Handle` of a different type, consider whether this is the correct handle type to store. If it is (i.e. the same handle id is used for multiple different Asset types) use `Handle::weak(handle.id)` to cast to a different type. ### [Allow higher order systems](https://github.com/bevyengine/bevy/pull/4833) diff --git a/content/learn/migration-guides/0.9-to-0.10.md b/content/learn/migration-guides/0.9-to-0.10.md index 1b4b925d30..47c73f1cb3 100644 --- a/content/learn/migration-guides/0.9-to-0.10.md +++ b/content/learn/migration-guides/0.9-to-0.10.md @@ -9,7 +9,7 @@ weight = 5 Bevy relies heavily on improvements in the Rust language and compiler. As a result, the Minimum Supported Rust Version (MSRV) is "the latest stable release" of Rust. -
+
### [Migrate engine to Schedule v3 (stageless)](https://github.com/bevyengine/bevy/pull/7267) @@ -242,7 +242,7 @@ enum AppState { `App::add_state` no longer takes an argument: the starting state is now controlled via the `Default` impl for your state type. -To access the current state of the the `States` type above, use `Res`, and access the tuple field via `.0`. +To access the current state of the `States` type above, use `Res`, and access the tuple field via `.0`. To queue up a state transition, use `ResMut>` and call [`.set(AppState::Menu)`](https://docs.rs/bevy/latest/bevy/ecs/schedule/struct.NextState.html#method.set). State transitions are now applied via the `apply_state_transitions` exclusive system, a copy of which is added [`CoreSet::StateTransitions`](https://docs.rs/bevy/latest/bevy/app/enum.CoreSet.html) when you call `App::add_state`. You can add more copies as needed, specific to the state being applied. diff --git a/content/news/2020-08-10-introducing-bevy/index.md b/content/news/2020-08-10-introducing-bevy/index.md index e087ed0662..2a6dd7bc04 100644 --- a/content/news/2020-08-10-introducing-bevy/index.md +++ b/content/news/2020-08-10-introducing-bevy/index.md @@ -105,7 +105,7 @@ And of course you can also create your own plugins. In fact, all engine and game ## Bevy ECS -All Bevy engine and game logic is built on top of a custom [Entity Component System](https://en.wikipedia.org/wiki/Entity_component_system) (or ECS for short). Entity Component Systems are a software paradigm that involves breaking data up into Components. Entities are unique ids assigned to groups of Components. For example, one entity might might have a `Position` and `Velocity` component, whereas another entity might have a `Position` and `UI` component. Systems are logic that runs on a specific set of component types. You might have a `movement` system that runs on all entities with a `Position` and `Velocity` component. +All Bevy engine and game logic is built on top of a custom [Entity Component System](https://en.wikipedia.org/wiki/Entity_component_system) (or ECS for short). Entity Component Systems are a software paradigm that involves breaking data up into Components. Entities are unique ids assigned to groups of Components. For example, one entity might have a `Position` and `Velocity` component, whereas another entity might have a `Position` and `UI` component. Systems are logic that runs on a specific set of component types. You might have a `movement` system that runs on all entities with a `Position` and `Velocity` component. The ECS pattern encourages clean, decoupled designs by forcing you to break up your app data and logic into its core components. diff --git a/content/news/2020-08-19-scaling-bevy/index.md b/content/news/2020-08-19-scaling-bevy/index.md index 86ff4965fd..2ec32a41a3 100644 --- a/content/news/2020-08-19-scaling-bevy/index.md +++ b/content/news/2020-08-19-scaling-bevy/index.md @@ -23,7 +23,7 @@ First, I want to take a moment to highlight just how wild the last week has been
-

2,200 Github Stars

+

2,200 GitHub Stars

diff --git a/content/news/2021-08-10-bevys-first-birthday/index.md b/content/news/2021-08-10-bevys-first-birthday/index.md index aaffda30e7..35d65e9e55 100644 --- a/content/news/2021-08-10-bevys-first-birthday/index.md +++ b/content/news/2021-08-10-bevys-first-birthday/index.md @@ -25,7 +25,7 @@ For those who don't know, Bevy is a refreshingly simple data-driven game engine * **August 10**: [Bevy 0.1](/news/introducing-bevy/) * Bevy's first public release! After months of working incognito, I released Bevy to the world. It was by no means complete, but it had most of the pillars in place to show the world what Bevy is (and could be): a modern and flexible renderer built on top of a modular Render Graph, a custom ECS with unrivaled ergonomics and competitive performance, 2D and 3D rendering features, asset handling, a modular app model that blurs the lines between engine developers and app developers, a custom UI system that integrates deeply with the engine, scenes, hot reloading, and blissfully productive iterative compile times. * **August 19**: [Absolutely Wild Public Reception](/news/scaling-bevy/) - * Just a week after release we became the 3rd most popular /r/rust post of all time, hit #2 on Hacker News, received 2,200 Github stars, merged pull requests from 26 new contributors, gained 644 Discord members, and received [sponsorships](https://github.com/sponsors/cart) that brought us 37% of the way to our first funding goal. + * Just a week after release we became the 3rd most popular /r/rust post of all time, hit #2 on Hacker News, received 2,200 GitHub stars, merged pull requests from 26 new contributors, gained 644 Discord members, and received [sponsorships](https://github.com/sponsors/cart) that brought us 37% of the way to our first funding goal. * **August 20**: [Reached our first funding goal ($1500 / month)](https://github.com/sponsors/cart) * [Embark became our first platinum sponsor](https://twitter.com/BevyEngine/status/1296525644004593664), which brought us past our first funding goal, allowing me to work on Bevy full time without eating into my savings. This honestly set the course for the rest of the year of Bevy development. * **August 20**: [The Amethyst forum post: "Bevy Engine - Addressing the elephant in the room"](https://community.amethyst.rs/t/bevy-engine-addressing-the-elephant-in-the-room/) @@ -46,7 +46,7 @@ For those who don't know, Bevy is a refreshingly simple data-driven game engine * [Bevy Assets](https://bevyengine.org/assets/) is a public library of community developed Bevy plugins, crates, assets, games, and learning materials. The website is fed by structured toml files in the [bevy-assets repo](https://github.com/bevyengine/bevy-assets). It has its roots in the awesome-bevy repo, our old unstructured markdown document with a list of community projects. It is still hot off the presses, but we have big plans for it! * **June 24**: [Reached our third funding goal ($4000 / month)](https://github.com/sponsors/cart) * Reaching this goal marked the point where I started thinking about Bevy as a career. I'm not making "market rate" for my skills and I'm still making less than 1/4th what I made as a Senior Software Engineer at Microsoft, but I'm no longer "just breaking even" and I'm starting to save some money. -* **August 2**: [Bevy hits 10,000 stars on Github](https://twitter.com/cart_cart/status/1422393321394085888) +* **August 2**: [Bevy hits 10,000 stars on GitHub](https://twitter.com/cart_cart/status/1422393321394085888) * I honestly can't believe we hit this so quickly. * **August 10**: Bevy is now one year old! @@ -54,13 +54,13 @@ For those who don't know, Bevy is a refreshingly simple data-driven game engine ![numbers](numbers.svg) -* **255** unique Bevy contributors on [Github](https://github.com/bevyengine) -* **10,030** [Github](https://github.com/bevyengine) stars -* **837** forks on [Github](https://github.com/bevyengine) -* **1,501** pull requests (1060 merged) on [Github](https://github.com/bevyengine) -* **1,112** issues (609 closed) on [Github](https://github.com/bevyengine) -* **1,895** commits on [Github](https://github.com/bevyengine) -* **153** [Github Discussions](https://github.com/bevyengine/bevy/discussions) +* **255** unique Bevy contributors on [GitHub](https://github.com/bevyengine) +* **10,030** [GitHub](https://github.com/bevyengine) stars +* **837** forks on [GitHub](https://github.com/bevyengine) +* **1,501** pull requests (1060 merged) on [GitHub](https://github.com/bevyengine) +* **1,112** issues (609 closed) on [GitHub](https://github.com/bevyengine) +* **1,895** commits on [GitHub](https://github.com/bevyengine) +* **153** [GitHub Discussions](https://github.com/bevyengine/bevy/discussions) * **110** [Bevy Assets](https://bevyengine.org/assets/) (plugins, crates, games, apps, and learning materials) * **57,349** downloads on [crates.io](https://crates.io/crates/bevy) * **93** [@BevyEngine](https://twitter.com/BevyEngine) retweets of Bevy community content on Twitter @@ -76,7 +76,7 @@ For those who don't know, Bevy is a refreshingly simple data-driven game engine I'm _so_ happy that Bevy quickly went from being "my engine" to being "our engine". It was beautiful to see so many people find passion projects in Bevy. Take a look at the feature author lists in the release blog posts (after Bevy 0.1). This community is _huge_, _wildly_ productive, and _intensely_ collaborative! -Our community is also extremely welcoming: we have an active [Github Q&A platform](https://github.com/bevyengine/bevy/discussions/categories/q-a) and [#help channel](https://discord.com/invite/bevy) on Discord (with over 82,000 messages). If you haven't already, [hop in to our Discord](https://discord.com/invite/bevy) and say hi! +Our community is also extremely welcoming: we have an active [GitHub Q&A platform](https://github.com/bevyengine/bevy/discussions/categories/q-a) and [#help channel](https://discord.com/invite/bevy) on Discord (with over 82,000 messages). If you haven't already, [hop in to our Discord](https://discord.com/invite/bevy) and say hi! ### Development Pace @@ -146,9 +146,9 @@ Bevy ECS is the interface we use to build both engine features and apps, so it w For those who think ECS is over-hyped ... I totally get it. ECS is _not_ the only way to build a good engine. Anyone who tells you otherwise either has an agenda or hasn't thought enough about the problem yet. ECS is, however, one of the best ways to standardize data representation and flow in a modular context. This is a problem that _every_ engine needs to solve and the results almost always end up looking _something_ like ECS, even if they don't use that label. ECS is also an extremely broad category, to the point of being almost meaningless. If thinking about Bevy ECS as "Bevy Data Layer" makes you happier, that is a completely valid mindset! Our APIs extend beyond traditional ECS definitions (and [we have plans to go further](https://github.com/bevyengine/bevy/pull/1627)). If you want to use an ECS-based engine because you've bought into the hype, I promise Bevy ECS can deliver :) -### Github Popularity +### GitHub Popularity -With over 10,000 stars, we are now the most popular Rust game engine on Github by a pretty wide margin. We are the [8th most popular game engine on Github](https://github.com/topics/game-engine). And Godot (currently holding the #1 spot with 40,900 stars) is starting to feel within our grasp, especially given their six year head start on us. If we make the same amount of progress next year, we'll be in the #2 spot! I'll be the first to say that popularity isn't everything. It isn't a measure of project maturity or feature set, but it _is_ a measure of how many people we reach and resonate with. Winning hearts and minds is an important part of scaling an open source project. I'm proud of this progress and I hope the rest of the community is too. +With over 10,000 stars, we are now the most popular Rust game engine on GitHub by a pretty wide margin. We are the [8th most popular game engine on GitHub](https://github.com/topics/game-engine). And Godot (currently holding the #1 spot with 40,900 stars) is starting to feel within our grasp, especially given their six year head start on us. If we make the same amount of progress next year, we'll be in the #2 spot! I'll be the first to say that popularity isn't everything. It isn't a measure of project maturity or feature set, but it _is_ a measure of how many people we reach and resonate with. Winning hearts and minds is an important part of scaling an open source project. I'm proud of this progress and I hope the rest of the community is too. ### Bevy Jobs @@ -254,7 +254,7 @@ Here are some predictions about Bevy's trajectory over the next year: * If the "Next Generation Bevy UI" effort is successful, people wanting to build "Rust GUI apps" will start reaching for Bevy. * We will break out of the "Rust gamedev enthusiast" circles. By the end of the year, Bevy will be brought up more regularly in the wider gamedev community alongside conversations about Unity, Unreal, and Godot. Not necessarily as a _direct_ competitor yet, but as a viable alternative for people that (1) want something new / innovative / different and (2) are willing to work around a smaller feature set and slightly less stable APIs. -If any of this excites you, we would love your help! Check out our code on [Github](https://github.com/bevyengine/bevy), start participating in the [Bevy Community](https://bevyengine.org/community/), and consider [sponsoring my work](https://github.com/sponsors/cart) to ensure I can continue building and leading this wildly ambitious project. +If any of this excites you, we would love your help! Check out our code on [GitHub](https://github.com/bevyengine/bevy), start participating in the [Bevy Community](https://bevyengine.org/community/), and consider [sponsoring my work](https://github.com/sponsors/cart) to ensure I can continue building and leading this wildly ambitious project. I'm looking forward to spending the next year with you all! diff --git a/content/news/2023-08-10-bevys-third-birthday/index.md b/content/news/2023-08-10-bevys-third-birthday/index.md index e759ff6789..915de42504 100644 --- a/content/news/2023-08-10-bevys-third-birthday/index.md +++ b/content/news/2023-08-10-bevys-third-birthday/index.md @@ -155,7 +155,7 @@ This will change. The Editor _is actually my top priority now_ and I aim to make ### Funding Bevy is Confusing -In the early days, I was the only person meaningfully working on Bevy. It made sense to have the Donate button link directly to my [Github Sponsors page](https://github.com/sponsors/cart). But things have changed! The [Bevy Org](/community/people/#the-bevy-organization) is now huge and there are plenty of people spending significant amounts of time making Bevy awesome. This year to help account for that, we made a new [Donate Page](/community/donate/) that describes the structure of the Bevy Org and provides a list of people accepting sponsorships. The Donate button now links to this page instead of directly to me. +In the early days, I was the only person meaningfully working on Bevy. It made sense to have the Donate button link directly to my [GitHub Sponsors page](https://github.com/sponsors/cart). But things have changed! The [Bevy Org](/community/people/#the-bevy-organization) is now huge and there are plenty of people spending significant amounts of time making Bevy awesome. This year to help account for that, we made a new [Donate Page](/community/donate/) that describes the structure of the Bevy Org and provides a list of people accepting sponsorships. The Donate button now links to this page instead of directly to me. However this is still suboptimal. How does a company or individual pick who to sponsor? It takes insider knowledge to know where the money would be "best spent". In the end I'm certain most people will opt for name recognition. And when I am often the public face of the project, that likely often means me. Bevy's funding should not be a popularity contest. diff --git a/content/news/2024-02-17-bevy-0.13/index.md b/content/news/2024-02-17-bevy-0.13/index.md index f8cf5cdfe9..e71abf0075 100644 --- a/content/news/2024-02-17-bevy-0.13/index.md +++ b/content/news/2024-02-17-bevy-0.13/index.md @@ -2387,7 +2387,7 @@ For a complete list of changes, check out the PRs listed below. * [fix patches for example showcase after winit update][11058] * [finish cleaning up dependency bans job][11059] * [Bump actions/upload-artifact from 2 to 4][11014] -* [Publish dev-docs with Github Pages artifacts (2nd attempt)][10892] +* [Publish dev-docs with GitHub Pages artifacts (2nd attempt)][10892] * [example showcase patches: use default instead of game mode for desktop][11250] * [Bump toml_edit in build-template-pages tool][11342] * [Miri is failing on latest nightly: pin nightly to last known working version][11421] diff --git a/content/news/2024-09-10-dream-job/index.md b/content/news/2024-09-10-dream-job/index.md new file mode 100644 index 0000000000..369a845b67 --- /dev/null +++ b/content/news/2024-09-10-dream-job/index.md @@ -0,0 +1,173 @@ ++++ +title = "I landed my dream job making a Rust game engine. Now what?" +date = 2024-09-10 +authors = ["Alice I. Cecile"] +[extra] +github = "alice-i-cecile" ++++ + +So I landed my dream job. Full-time open source building a game engine in Rust. Absolutely no meetings. What more could you ask for? +With a very unconventional background (plant ecology, self-taught programming and years of disability), it's flatly astonishing to be [supported](https://bevyengine.org/donate/) by such an awesome community: surrounded and empowered by experts and beginners alike making incredible things together. + +But now what? +[Bevy's fourth birthday](@/news/2024-08-10-bevys-fourth-birthday/index.md) has rolled around, and `@cart` has put out a call for others to reflect on the year behind us, and plan for the year ahead. +How have my first few months of Serious Employment at the Bevy Foundation gone, and what am I cooking up? + + + +## Quasi-Hobby to Day Job + +For years before I started working at the Bevy Foundation, I've helped out around Bevy: writing docs, triaging issues, reviewing PRs, designing complex systems and polishing off rough corners. + +I'd pitch in where I could, tackling the million small tasks in moments between working on side projects, the occasional bits of consulting and making sure life at home was running smoothly. +And over the years that really added up! +Reading, thinking, communicating: I've never been the sort to write reams of code for specific subsystems, or to dive into the most obscure bugs. +But if I listened to people talk about what they needed, chewed on it for a bit, and then passed it on to the people who wanted to help, I found I could be *remarkably* effective! + +It was a good groove. +But then all of a sudden, working on Bevy was my day job! +That means 40 hours a week, 8 hours a day, 9-5 Monday to Friday in the office, right? +Well, okay, sure, no one cares when I work. Or exactly how much I work per day. And we don't even have an office! +But surely, that was the platonic ideal of what Real Work should look like, and I should be aspiring to it, even if it would forever be out of reach. + +Actually no, not so much. +At first, I tried to stick to this (entirely of my own volition!): Monday to Friday, 8 hours a day, strict start and stopping time. +I focused on big initiatives, tried to code more, and made *sure* I wasn't working outside of the allowed time blocks. + +It made me *miserable*. +Pushing myself to work for long blocks at a time was physically and mentally demanding. +I had to actively force myself *not* to triage that issue, leave that comment, or tackle that PR. +And conversations across our team of dozens of globally-distributed contributors simply didn't have the decency to stay nicely confined to my 9-5 schedule! + +So, how did I square the circle? +The time and freedom to tackle bigger projects was a huge advantage, but all those little tasks still mattered! +And even though moving to a more flexible schedule was probably healthy for me, +I needed to make sure that work didn't consume my whole life. + +My solution: **focus tasks**. +Every work day (but not days off!), I would pick a single task to focus on. +Writing a piece of documentation, reviewing a complex PR, adding a feature, refactoring a complex bit of code, preparing a design doc, running the weekly Merge Train... +I would focus on that when I was feeling well, get done what I could, and as soon as my focus broke or the task was completed, that was it. I was "done work" for the day. + +To complement this, the strict 9-5 M-F schedule would be relaxed. I could work whenever I felt like it (turns out, for me, that's quite a bit): +tackling the million little things that help keep Bevy ticking along. +But there would be no *obligation*: no sense that I *must* do these things, or must do them in a timely fashion. +I could be there for the impromptu late night design chats, but still disconnect during date night because, after all, I finished work *hours* ago. + +This balance has worked really well for me: letting me drive forward larger initiatives (`bevy_color`! A huge `leafwing-input-manager` refactor! The 0.14 release!) without falling behind on the flood of notifications. +Would I recommend you use it? Probably not! It requires a degree of flexibility that many organizations won't afford you, you need to be driven and self-motivated and frankly, the work-life boundary is far blurrier than most people can live with. +But for someone working full-time in open source? Absolutely! + +## Dream Jobs Are Still Jobs + +So, having worked at the Bevy Foundation for a few months: is this really my dream job? How does it live up to my expectations? +Despite my boundless idealism, working for a non-profit you care about is not a panacea: if the working conditions suck, +the fact that you're Doing Good won't get you through the day. + +On the bright side, I have: + +- a mission I believe in +- a comfortable living (my latest budget says $84k CAD pre-tax) +- the opportunity to meet and learn from incredible people: within Bevy, Rust and game dev more broadly +- a work-from-home arrangement with incredible flexibility +- huge levels of agency over what I work on +- generous European-style vacation and sick-leave policies + +But it's not perfect, that's all balanced out by: + +- a remarkably public role, where everything I do from day-to-day is visible +- an incredibly small team of non-volunteers that serve as a backstop for all of the needful but tedious things that need to be done +- fuzzy work-life boundaries +- a salary that is *much* lower than what I could be making +- existential dread caused by relying entirely on [generous donors](https://bevyengine.org/donate) to keep both myself and the project I love afloat + +Honestly, it's a lot like founding a startup. +It's just instead of having a small-but-nonzero chance of becoming wealthier than anyone ever needs to be, +I have a chance to change an industry for the better and help people make cool things! + +## Learn or Drown + +The most striking thing about it though, is the extent to which I have to *keep* learning and growing. +Rust? ECS? Technical writing? Project management? Input management? Community management? + +I can't get complacent and only work within my comfort zone of skillsets that I've mastered. +There's always a new stalled-out work area that needs leadership, brilliant but complex PRs to review, and thorny problems to cut through. +Even if my natural proclivities are focused on design and communication, I need to be *fluent* in every single area needed to make games. +Experts are great, but keeping things moving along means I have to be able to understand what they're saying and integrate it into a broader project context. + +Over the next year, I hope to get comfortable with basic custom rendering, muck about with Bevy's asset solution and learn about reactive UI in earnest. +Should be fun, and it might even drive some progress on my *own* games. + +## Working Groups: Self-Organization and Empowerment + +I've long believed that building systems and altering incentives is the best way to fix problems for good. +When I first started working at Bevy, we had a pair of twin problems: contributors were frustrated by the lack of direction and reviews for complex but valuable initiatives, while maintainers were out of bandwidth and frustrated with efforts that petered out as individual contributors got busy. + +Enter [working groups](https://github.com/bevyengine/bevy/pull/13162): scoped, collaborative efforts to define, explore and tackle complex problems. +I've been incredibly pleased to see how they've turned out: + +- an emphasis on clear, well-motivated designs +- a clear list of things that we're actively tackling +- a space to focus community efforts towards a shared goal +- a ready-made source of reviewers for complex efforts +- a mechanism for ambitious contributors to build consensus and radically change things + +The `bevy_color` working group was a wonderful bubbling hub of activity that tackled all of the gnarly corners of writing a color library from scratch, +while the 0.14 release working group really helped take the pressure off of Cart and I, even if it was a slog. + +I'm really excited to see what the open groups (relations, text, audio, picking, contributing guide, scenes, render graph and curves) put together over the next year! +I'll stir the pot periodically to keep things moving along smoothly, but overall I'm delighted by how well this experiment in self-organization has gone. + +## Technical Future: UI That Doesn't Suck + +Right now, Bevy has a critical technical limitation: our UI solution sucks. +While of course you could argue that *all* UI solutions suck, `bevy_ui` is remarkably underbaked. +There's too much boilerplate, there are virtually no premade widgets, and most of the hard problems are handed off to the user. + +While things *have* improved substantially since Bevy's initial release, `bevy_ui` operates at the same level as HTML: just raw data structures to be manipulated. +And for most of our users, that simply isn't enough! +Bevy's an incredible choice for CAD software, or complex simulation games, or dev tooling (like the fabled editor), *except* that building UIs takes too long and polishing them is nearly impossible. + +While I've shared [my own vision for what `bevy_ui` could be](https://hackmd.io/@bevy/HkjcMkJFC), I trust @cart (and @viridia, @StarArawn, @UkoeHB and @SanderMertens) to figure out most of the fancy incremental, reactive, data-driven bits. +Instead, I want to clean up all the low-hanging fruit that drags our UI solution down, no matter what solution they land on. + +Over the course of the next year, I want to: + +- swap to `cosmic_text`, and properly support non-Latin character sets +- make it easier to reason about fonts and how they're related +- support basic localization and markup-style rich text +- port `bevy_ui` to a polished picking paradigm +- make sure that simple alternatives to flexbox layout can be used for those who prefer it +- add focus management, making it easy to navigate UI with keyboards, gamepads and screen readers +- upstream `leafwing-input-manager`, giving Bevy first-party support for keybindings for both UI and gameplay +- ship a modest collection of functional standard widgets: radio buttons, text input, sliders and more +- write examples that cover real use cases: splash screens, settings menus, drag-and-drop inventories, UI mockups for various game genres... + +None of these things will radically change how `bevy_ui` works, but taken together, should lead to a night-and-day difference in the experience for both devs and end users. + +## Product Future: Beyond Rust Gamedev + +In both Rust-focused and gamedev-focused spaces, Bevy is often *defined* by the fact that it's written in Rust. +But thinking about game engines in this way is a trap, both for Bevy and for the ecosystem as a whole. + +Overwhelmingly, professional game developers don't decide that they're going to use Rust, look at the options within the set of Rust game engines and then choose one. +While hobbyists and those seeking to learn Rust *might* choose an engine that way (Rust is delightful and making games is a great way to learn), +it's an ineffective way to make business-critical decisions! + +Instead, they look at the *full* set of engines and what they have to offer: Unity, Unreal, Godot and dozens more. +Every team and every project has different needs and idiosyncratic preferences: there will never be an ur-engine that others are simply *wrong* for not choosing. +But if you want to compete within a crowded space, you need to both carve out and communicate a niche: a set of things that you're *uniquely* good at. + +Simply being the best, most popular, or most featureful game engine in Rust isn't enough, and frankly, barely matters at all. +Rust is fantastic, and I think in the long-run it'll be a major advantage, but right now, the game industry perception is that it's immature and slow to develop games using it. + +To survive as anything beyond a hobby engine, you need to attract commercial teams building serious games, built on a budget with mixed teams of programmers, artists and designers. +While you don't need to be better than the big kids in *every* way, you need to be better than them in some ways, and the *rational* choice for some set of teams needs to be to pick your engine. + +While we're not the rational choice yet for most projects and teams, I want to set us up for real success in the future. +In the coming year, I want to network more with gamedevs outside of Rust (say hi!), learn more about the workflows that real indie teams use and challenges that they face. +While the small improvements trickle in, one PR at a time, I want to set my eyes on the horizon, understand what talented small teams are looking for out of their next engine, and make sure we're building towards those goals. + +No one is writing the next Call of Duty in Bevy (yet!): the requirements around rendering, tooling, training, console support and risk are way too strict. +But what would it take to convince teams to write the next Factorio, Terraria, Slay the Spire, Hollow Knight or Hades in Bevy? +Time to find out! diff --git a/content/news/2024-09-11-community-reflection-on-bevys-fourth-year/index.md b/content/news/2024-09-11-community-reflection-on-bevys-fourth-year/index.md new file mode 100644 index 0000000000..f68d1a0ce3 --- /dev/null +++ b/content/news/2024-09-11-community-reflection-on-bevys-fourth-year/index.md @@ -0,0 +1,64 @@ ++++ +title = "Community Reflection on Bevy's Fourth Year" +date = 2024-09-11 +authors = ["Carter Anderson"] +[extra] +twitter = "cart_cart" +github = "cart" +youtube = "cartdev" ++++ + +[@cart](https://www.twitter.com/cart_cart) here (Bevy's creator and Project Lead) with another update! A month ago was Bevy's Fourth Birthday! As is tradition, I took that as a chance to reflect on the past year and outline my hopes and dreams for the future. You can read that in my [Bevy's Fourth Birthday](/news/bevys-fourth-birthday) post. + +I also encouraged the Bevy community to write their own reflections on Bevy's fourth year in a similar style, and to [post them here](https://github.com/bevyengine/bevy-website/issues/1592). + + + +## What is Bevy? + +For those who don't know, Bevy is a refreshingly simple data-driven game engine built in Rust. Bevy is also free and open source forever! You can grab the full [source code](https://github.com/bevyengine/bevy) on GitHub. We have a [Quick Start Guide](/learn/quick-start). You can also check out [Bevy Assets](/assets) for a library of community-developed plugins, crates, games, and learning resources. + +## Reflections + +We had plenty of responses this year! Here is a central collection of **Bevy's Fourth Birthday** posts: + +* **Carter Anderson ([@cart](https://github.com/cart))** Project LeadMaintainer + * [Bevy's Fourth Birthday](/news/bevys-fourth-birthday) +* **Alice Cecile ([@alice-i-cecile](https://github.com/alice-i-cecile))** Maintainer + * [I landed my dream job making a Rust game engine. Now what?](/news/dream-job) +* **Thierry Berger ([@Vrixyz](https://github.com/Vrixyz))** + * [Happy Bevybirthday](https://thierryberger.com/blog/bevy-4th-birthday/) +* **BD103 ([@BD103](https://github.com/BD103))** + * [4 Years of Bevy](https://bd103.github.io/blog/2024-08-18-4-years-of-bevy) +* **JMS55 ([@JMS55](https://github.com/JMS55))** + * [Bevy's Fourth Birthday - A Year of Meshlets](https://jms55.github.io/posts/2024-08-30-bevy-fourth-birthday/) +* **Mikael Matveinen ([@mmatvein](https://github.com/mmatvein))** + * [Bevy's 4th birthday: Reflections in the context of our own project](https://www.reddit.com/r/bevy/comments/1f712hl/bevys_4th_birthday_reflections_in_the_context_of/) +* **Peter Hayman ([@mrchantey](https://github.com/mrchantey))** + * [Bevy Turns Four](https://beetmash.com/blog/bevy-turns-four) +* **doomy ([@piedoom](https://github.com/piedoom))** + * [birthday_system.system()](https://doomy.org/bevys-fourth-birthday/) +* **Chris Biscardi ([@ChristopherBiscardi](https://github.com/ChristopherBiscardi))** + * [Bevy's Fourth Birthday](https://gist.github.com/ChristopherBiscardi/ab3fc92c3ba83e46cb5577bda2d287bc) + +## What are we working on right now? + +Here are some things we have coming up! + +* [Next Generation Scene / UI](https://github.com/bevyengine/bevy/discussions/14437): We're working on a brand new modern scene system that will make defining Bevy scenes in code, asset files, _and_ the upcoming Bevy Editor _much_ nicer. This will also be the foundation for the Bevy Editor itself, which will be built _on top_ of the new Scene / UI system. In general, this will be a massive step forward for Bevy's capabilities and user experience. Read the whole proposal for details! +* [Required Components](https://github.com/bevyengine/bevy/pull/14791): This is the first step in our plan for Bevy's Next Generation Scene / UI system, and it has already been merged into our main branch! It _significantly_ improves the legibility and composability of defining and spawning components. We're in the process of porting Bevy's built-in components / bundles to the new system, and if all goes well, this will be included in the next Bevy release. +* [Retained Render World](https://github.com/bevyengine/bevy/pull/14449): To facilitate parallel pipelined rendering, Bevy has both an "app world" and a "render world". This requires synchronizing the two worlds. Currently, Bevy clears the render world every frame and then repopulates it, which incurs overhead. By switching to a "retained render world", we can avoid redundant work across frames by caching entity data on the renderer side across frames. +* [Function Reflection](https://github.com/bevyengine/bevy/pull/13152): We're making it possible to dynamically call functions via Bevy Reflect, which unlocks scenarios like calling Rust functions referenced in assets such as scenes! We'll use this feature as part of the Next Generation Scene / UI effort. +* [Order Independent Transparency](https://github.com/bevyengine/bevy/pull/14876): A new alternative to sorted alpha blending that does not require sorting draw objects before drawing them. This can both save CPU cycles and improve transparency behavior in some cases. +* [Improved Text API](https://github.com/bevyengine/bevy/discussions/15014): In preparation for Next Generation Scene / UI, we're reworking our `Text` component APIs to be significantly more straightforward to use. +* [Cosmic Text Rendering](https://github.com/bevyengine/bevy/pull/10193): We've switched to [cosmic-text](https://github.com/pop-os/cosmic-text) for our text rendering, which improves our ability to handle scripts and ligatures (among other improvements). +* [Upstreaming bevy_mod_picking](https://github.com/bevyengine/bevy/pull/13677): We're upstreaming aspects of [bevy_mod_picking](https://github.com/aevyrie/bevy_mod_picking/) and porting it to Bevy's new Observer system. This provides APIs for picking (identifying / clicking on / selecting) entities in 2D and 3D space. +* [Bevy CLI](https://hackmd.io/cCHAfbtaSviU_MDnbNHKxg): We're building a Bevy command line interface, which will be the one-stop-shop for doing things like generating new Bevy projects from templates, running the asset preprocessor, running Bevy-specific lints, and more! + +**Bevy 0.15** will be coming out in a month or so, and some of the items above will land in it! + +Here is to another year of Bevy! + +\- [@cart](https://github.com/cart/) + + diff --git a/content/news/2024-09-25-bevy-foundation-501c3/index.md b/content/news/2024-09-25-bevy-foundation-501c3/index.md new file mode 100644 index 0000000000..9895dd3d60 --- /dev/null +++ b/content/news/2024-09-25-bevy-foundation-501c3/index.md @@ -0,0 +1,65 @@ ++++ +title = "Bevy Foundation is now a 501(c)(3) Public Charity" +date = 2024-09-25 +authors = ["Carter Anderson"] +[extra] +twitter = "cart_cart" +github = "cart" +youtube = "cartdev" ++++ + +In March we [announced the Bevy Foundation](/news/bevy-foundation/), our new non-profit dedicated to developing Bevy and teaching people how to use it. At that time, we applied for federal 501(c)(3) public charity status, which would give us tax-exempt status in the United States and make donations tax-deductible. It introduces stricter operational constraints that help protect the integrity of our mission and our community. + +I am excited to announce that the Bevy Foundation has been granted 501(c)(3) public charity status! + + + +## What does this mean for Bevy? + +1. We are exempt from income tax on donations we receive (including the donations we have already received this year). This means 100% of the donations we receive go toward furthering our mission. +2. Donations to Bevy Foundation (including all past donations that occurred this year) are now tax-deductible in the United States. +3. Many employers have donation-matching programs for 501(c)(3)s. It is worth checking to see if your employer will match your donation! +4. There are many grant opportunities out there for 501(c)(3)s. These are now on the table for the Bevy Foundation. +5. We now must [operate under the constraints of a 501(c)(3) public charity](https://www.501c3.org/what-is-a-501c3/) +6. We must file a yearly report that outlines our activities (IRS form 990). + +I am personally very excited about this. 501(c)(3) public charity status, because of its constraints, buys us more public trust than the more general state-level non-profit status. Each donation can go further, and there are now more opportunities for financial support! + +## Every.org: our new donation platform + +As a 501(c)(3) we are now qualified to use [Every.org](https://www.every.org/) as our donation platform. Every.org is _also_ a 501(c)(3) that exists to make 501(c)(3) fundraising as straightforward and cheap as possible. They take _no_ platform fees, and if you pay directly with a bank account, there are _literally_ zero fees. 100% of your donation goes to Bevy Foundation. If you pay with a credit card or a payment processor like Apple Pay, you still pay those platform fees, but they are as low as possible. + +We still support Stripe (our old platform) to give people as many options as possible. But we now prefer Every.org and default to it where we can, as it provides _much_ better rates: + +| | Every.org | Stripe | +| ----- | --------- | ------ | +| Bank Fee | 0% | 0.8% | +| Subscription Fee | 0% | 0.5% (increasing to 0.7% next year) | +| Card Fee | 2.2% + $0.30 | 2.2% + $0.30 | + +These fees really add up over time, so using Every.org is a _huge_ win for us! + +Every.org also supports easy one-time payments with custom amounts (an often requested feature). See our [expanded donation options](/donate/options) page for details. + +## New Bevy Foundation Emails + +As part of this announcement, we're also rolling out new `bevyengine.org` emails: + +* : The new way to ask Bevy leadership for support. This replaces `bevyengine@gmail.com`. +* : The best way to reach Bevy Foundation board members. + +The Bevy Maintainers / Bevy Foundation Board Members now also have individual `bevyengine.org` emails: + +* Carter Anderson: +* Alice Cecile: +* François Mockers: +* Robert Swain: +* James Liu: + +## Please Donate! + +With these changes, there has never been a better time to [donate to the Bevy Foundation](/donate). In addition to the default monthly donations, custom one-time donations are also now open, so if you were waiting for those ... now is the time to hop aboard! + +Bevy will always be free and open-source, but it isn't free to make! Because Bevy is free, we rely on the generosity of the Bevy community to fund our efforts. If you are a happy user of Bevy or you believe in our mission, please consider [donating to the Bevy Foundation](/donate)... every bit helps! + +Donate heart icon diff --git a/generate-assets/Cargo.toml b/generate-assets/Cargo.toml index 42fbbd138d..257dfcb22b 100644 --- a/generate-assets/Cargo.toml +++ b/generate-assets/Cargo.toml @@ -1,7 +1,7 @@ [package] name = "generate-assets" authors = [ - "Bevy Contributors ", + "Bevy Contributors ", "Carter Anderson ", ] license = "MIT" diff --git a/generate-assets/src/lib.rs b/generate-assets/src/lib.rs index cb45d58329..effb9fd1a9 100644 --- a/generate-assets/src/lib.rs +++ b/generate-assets/src/lib.rs @@ -556,7 +556,7 @@ fn search_bevy_in_manifest_dependencies( /// Gets the bevy version from the `Cargo.toml` bevy dependency provided. /// /// Returns the version number if available. -/// If is is a git dependency, return either "main" or "git" for anything that isn't "main". +/// If is a git dependency, return either "main" or "git" for anything that isn't "main". fn get_bevy_manifest_dependency_version(dep: &cargo_toml::Dependency) -> Option { match dep { cargo_toml::Dependency::Simple(version) => Some(version.to_string()), diff --git a/generate-community/Cargo.toml b/generate-community/Cargo.toml index fe533bfccd..c9f6d304cf 100644 --- a/generate-community/Cargo.toml +++ b/generate-community/Cargo.toml @@ -1,7 +1,7 @@ [package] name = "generate-community" authors = [ - "Bevy Contributors ", + "Bevy Contributors ", ] license = "MIT" edition = "2021" diff --git a/generate-errors/Cargo.toml b/generate-errors/Cargo.toml index be6e514ae6..10dee3affd 100644 --- a/generate-errors/Cargo.toml +++ b/generate-errors/Cargo.toml @@ -1,7 +1,7 @@ [package] name = "generate-errors" authors = [ - "Bevy Contributors ", + "Bevy Contributors ", "Carter Anderson ", ] license = "MIT" diff --git a/generate-release/Cargo.toml b/generate-release/Cargo.toml index 356ac7d36c..1c0d0c2a2c 100644 --- a/generate-release/Cargo.toml +++ b/generate-release/Cargo.toml @@ -15,6 +15,7 @@ dotenvy = "0.15.6" serde_json = "1.0.91" rayon = "1.10.0" thiserror = "1.0.61" +toml = "0.8.19" [lints] workspace = true diff --git a/generate-release/README.md b/generate-release/README.md index d0615c7fea..3086997493 100644 --- a/generate-release/README.md +++ b/generate-release/README.md @@ -4,12 +4,14 @@ This CLI tool is used to generate all the skeleton files required to create a ne For a bit more background see this issue: -All commands assume they are ran in the `/generate-release` folder. +The commands can be run from anywhere inside the workspace folder. If you have a `.env` file, this will only work if it is located at the root of the workspace. Each command will generate files in the `/release-content/{release-version}` folder. The `release-version` is an argument to all commands. Each command have a `--from` and `--to` argument. You can pass it a Git branch, tag, or commit. +To create issues for the `release-notes` subcommand, you need to pass the `--create-issues` flag, otherwise it performs a dry-run that does not have lasting consequences. This should probably only be done for the initial run, after a regular dry-run has been done to confirm the tool is working as expected. + Before running the command, you'll need to generate a GitHub API token at . It's easier to use classic tokens. The token must have `repo` permissions to be able to open issues (and PRs) on your behalf. @@ -22,16 +24,18 @@ GITHUB_TOKEN=token_string_copied_from_github Here's an example for the commands used to generate the `0.14` release: ```shell -cargo run -- --from v0.13.0 --to main --release-version 0.14 migration-guides -cargo run -- --from v0.13.0 --to main --release-version 0.14 release-notes -cargo run -- --from v0.13.0 --to main --release-version 0.14 changelog -cargo run -- --from v0.13.0 --to main --release-version 0.14 contributors +cargo run -p generate-release -- --from v0.13.0 --to main --release-version 0.14 migration-guides +cargo run -p generate-release -- --from v0.13.0 --to main --release-version 0.14 release-notes +cargo run -p generate-release -- --from v0.13.0 --to main --release-version 0.14 changelog +cargo run -p generate-release -- --from v0.13.0 --to main --release-version 0.14 contributors ``` ## Generating a release To generate a release from scratch, run all these commands then add the new migration guide and blog post to their respective `/content` folder. When doing so, it's important to use the `public_draft` feature to hide those pages until the day of the release. For the `public_draft` feature, you'll need to provide it a GitHub issue number, it's recommended to point it to an issue tracker for the current release being worked on. The issue needs to be on the `bevy-website` repo. +When you're merging or editing notes and guides, keep in mind that this tool will not regenerate notes or guides that still have a PR number in any note or guide's metadata, contained in the `_.toml`. This means to merge multiple PRs into one note or guide you simply remove one `[[release_notes]]` or `[[guides]]` entry, and move its PR number to the merged entry that is the sum of all the merged PRs. For editing, this means the other metadata will also not be regenerated if the PR number still exists in the metadata. + The following sections go in more details on each parts of the process. ### Migration Guides @@ -45,15 +49,22 @@ Inside that file, you should have something that looks like this: ```markdown +++ -title = "0.13 to 0.14" +# Let Xa be the old major version, and ya the old minor version, +# and Xb be the new major version, and yb the new minor version. +# +# Change the Bevy versions below to match these! +title = "Xa.ya to Xb.yb" insert_anchor_links = "right" [extra] -weight = 9 -long_title = "Migration Guide: 0.13 to 0.14" +# Let N be the weight of the prior / last migration guide, plus one. +weight = N +long_title = "Migration Guide: Xa.ya to Xb.yb" +# GitHub issue number for tracking this release's +# migration guides or news post. public_draft = _release tracking issue number_ +++ -{{ migration_guides(version="0.14") }} +{{ migration_guides(version="Xb.yb") }} ``` The most important part of this is the `migrations_guides` shortcode. It will get the list of guides from the `_guides.toml` file and combine all the separate file and generate appropriate markup for it. @@ -74,9 +85,15 @@ Once all those files are generated you'll need to create a new blog post in `/co ```markdown +++ -title = "Bevy 0.14" -date = 2024-05-17 +# Let X be the major version, and y the minor version. +# Change the Bevy release versions below to match this one! +title = "Bevy X.y" +# Insert a date in the year, month, day format. +# This should be the date that the post will be posted. +date = YYYY-MM-DD [extra] +# GitHub issue number for tracking this release's +# news post. public_draft = _release tracking issue number_ +++ @@ -84,15 +101,18 @@ public_draft = _release tracking issue number_ -{{ release_notes(version="0.14") }} +{{ release_notes(version="X.y") }} ## What's Next? {{ support_bevy() }} -{{ contributors(version="0.14") }} -{{ changelog(version="0.14")}} +{{ contributors(version="X.y") }} +{{ changelog(version="X.y")}} ``` The most important part of this is the `release_notes`, `changelog`, and `contributors` shortcodes. `release_notes` will get the list of release notes from the `_release_notes.toml` file and combine all the separate file and add them to this file. `contributors()` will load the `contributors.toml` file and generate the necessary markup. `changelog()` will load the `changelog.toml` file and generate the necessary markup. + +> [!NOTE] +> The `contributors` field in `_release_notes.toml` is for all non-PR-author contributors to the PR; they should be added to the `authors` field on a case-by-case basis depending on level of involvement. diff --git a/generate-release/src/migration_guides.rs b/generate-release/src/migration_guides.rs index 77c9bc0665..13181dacd9 100644 --- a/generate-release/src/migration_guides.rs +++ b/generate-release/src/migration_guides.rs @@ -1,14 +1,34 @@ use anyhow::Context; +use serde::Deserialize; use crate::{ github_client::{GithubClient, GithubIssuesResponse}, helpers::{get_merged_prs, get_pr_area}, markdown::write_markdown_section, }; -use std::{collections::BTreeMap, io::Write as IoWrite, path::PathBuf}; +use std::{ + collections::{BTreeMap, BTreeSet}, + fs::{self, OpenOptions}, + io::Write as IoWrite, + path::PathBuf, +}; type PrsByAreaBTreeMap = BTreeMap, Vec<(String, GithubIssuesResponse)>>; +#[derive(Deserialize, Clone)] +struct MigrationGuides { + guides: Vec, +} + +#[allow(dead_code)] +#[derive(Deserialize, Clone)] +struct MigrationGuide { + title: String, + prs: Vec, + areas: BTreeSet, + file_name: String, +} + pub fn generate_migration_guides( from: &str, to: &str, @@ -22,18 +42,49 @@ pub fn generate_migration_guides( // Create the directory that will contain all the migration guides std::fs::create_dir_all(&path).context(format!("Failed to create {path:?}"))?; - // We'll write the file once at the end when all the metdaata is generated - let mut guides_metadata = Vec::new(); + let mut guides_metadata = if overwrite_existing { + vec![] + } else { + // If there is metadata that already exists, + // and would contain info such as which PR already + // has an entry, then get it and use it for that. + let preexisting_metadata_file = fs::read_to_string(path.join("_guides.toml")).ok(); + // Deserializes the file inside the option into the `MigrationGuides` struct, + // and then transposes / swaps the internal result of that operation to external, + // and returns the error of that result if there is one, + // else we have our preexisting metadata, ready to use. + let preexisting_metadata: Option = preexisting_metadata_file + .as_deref() + .map(toml::from_str) + .transpose()?; + + eprintln!("metadata exists? {}", preexisting_metadata.is_some()); + // Populate the metadata to be written with the + // preexisting metadata so that it is not lost, + // or overwritten. + preexisting_metadata + .map(|metadata| metadata.guides) + .unwrap_or_default() + }; // Write all the separate migration guide files for (area, prs) in areas { - let mut prs = prs; - // The PRs inside each area are sorted by close date - // This doesn't really matter for the final output, - // but it's useful to keep the metadata file in the same order between runs - prs.sort_by_key(|k| k.1.closed_at); - for (title, pr) in prs { + // If a PR is already included in the migration guides, + // then do not generate anything for this PR. + let mut pr_already_generated = false; + + for migration_guide in guides_metadata.iter() { + if migration_guide.prs.contains(&pr.number) { + pr_already_generated = true; + } + } + + if pr_already_generated { + eprintln!("PR #{} already exists", pr.number); + continue; + } + // Slugify the title let title_slug = title .replace(' ', "_") @@ -48,30 +99,71 @@ pub fn generate_migration_guides( // 64 is completely arbitrary but felt long enough and is a nice power of 2 file_name.truncate(64); - // Generate the metadata block for this migration - // We always re-generate it because we need to keep the ordering if a new migration is added - let metadata_block = generate_metadata_block(&title, &file_name, &area, pr.number); + // Add the markdown extension + file_name = format!("{file_name}.md"); + + let file_path = path.join(&file_name); - let file_path = path.join(format!("{file_name}.md")); - if file_path.exists() && !overwrite_existing { - // Skip existing files because we don't want to overwrite changes when regenerating - continue; - } if write_migration_file( &file_path, pr.body.as_ref().context("PR has no body")?, pr.number, )? { - guides_metadata.push(metadata_block); + guides_metadata.push(MigrationGuide { + title, + prs: vec![pr.number], + areas: area.clone().into_iter().collect(), + file_name, + }); } } } - // Write the metadata file - let mut guides_toml = std::fs::File::create(path.join("_guides.toml")) + // Sort by: Area in ascending order (empty areas at the end), and Title in ascending order + guides_metadata.sort_by(|a, b| { + let areas_cmp = match (a.areas.is_empty(), b.areas.is_empty()) { + (false, false) => { + let a_areas = a.areas.clone().into_iter().collect::>().join(" "); + let b_areas = b.areas.clone().into_iter().collect::>().join(" "); + + a_areas.cmp(&b_areas) + } + (false, true) => std::cmp::Ordering::Less, + (true, false) => std::cmp::Ordering::Greater, + (true, true) => std::cmp::Ordering::Equal, + }; + + areas_cmp.then_with(|| a.title.cmp(&b.title)) + }); + + // Create the metadata file, and overwrite it if it already exists. + // + // Note: + // The file, while overwritten, + // may still contain the same underlying data gotten from + // the preexisting metadata earlier, if overwrite_existing is false, + // thus preserving the data even if the file itself is overwritten. + let mut guides_toml = OpenOptions::new() + .write(true) + .truncate(true) + .create(true) + .open(path.join("_guides.toml")) .context("Failed to create _guides.toml")?; + for metadata in guides_metadata { - writeln!(&mut guides_toml, "{metadata}")?; + // Generate the metadata block for this migration. + // + // We always freshly generate and write this data to the file, + // rather than appending to the end-of-file, + // so that we can maintain proper ordering of the entries. + let metadata_block = generate_metadata_block( + &metadata.title, + &metadata.file_name, + &metadata.areas.into_iter().collect::>(), + &metadata.prs, + ); + + writeln!(&mut guides_toml, "{metadata_block}")?; } Ok(()) @@ -98,7 +190,7 @@ fn get_prs_by_areas( let has_breaking_label = pr .labels .iter() - .any(|l| l.name.contains("C-Breaking-Change")); + .any(|l| l.name.contains("M-Needs-Migration-Guide")); // We want to check for PRs with the breaking label but without the guide section // to make it easier to track down missing guides @@ -122,15 +214,20 @@ fn generate_metadata_block( title: &str, file_name: &String, areas: &[String], - pr_number: u64, + pr_number: &[u64], ) -> String { format!( r#"[[guides]] title = "{title}" -url = "https://github.com/bevyengine/bevy/pull/{pr_number}" +prs = [{pr_numbers}] areas = [{areas}] -file_name = "{file_name}.md" +file_name = "{file_name}" "#, + pr_numbers = pr_number + .iter() + .map(|pr| pr.to_string()) + .collect::>() + .join(", "), areas = areas .iter() .map(|area| format!("\"{area}\"")) diff --git a/generate-release/src/release_notes.rs b/generate-release/src/release_notes.rs index 3f369cbee1..af48024bed 100644 --- a/generate-release/src/release_notes.rs +++ b/generate-release/src/release_notes.rs @@ -1,4 +1,5 @@ use anyhow::Context; +use serde::Deserialize; use crate::{ github_client::{BevyRepo, GithubClient, GithubIssuesResponse, IssueState}, @@ -6,10 +7,26 @@ use crate::{ }; use std::{ collections::HashSet, + fs::{self, OpenOptions}, io::Write, path::{Path, PathBuf}, }; +#[derive(Deserialize, Clone)] +struct ReleaseNotes { + release_notes: Vec, +} + +#[expect(dead_code)] +#[derive(Deserialize, Clone)] +struct ReleaseNote { + title: String, + authors: Vec, + contributors: Vec, + prs: Vec, + file_name: String, +} + pub fn generate_release_notes( from: &str, to: &str, @@ -20,12 +37,12 @@ pub fn generate_release_notes( create_issues: bool, ) -> anyhow::Result<()> { // Get all PRs that need release notes - let prs = get_merged_prs(client, from, to, Some("C-Needs-Release-Note"))?; + let prs = get_merged_prs(client, from, to, Some("M-Needs-Release-Note"))?; // Create the directory that will contain all the release notes std::fs::create_dir_all(&path).context(format!("Failed to create {path:?}"))?; - // We'll write the file once at the end when all the metdaata is generated + // We'll write the file once at the end when all the metadata is generated let mut notes_metadata = Vec::new(); // Generate the list of all issues so we don't spam the repo with duplicates @@ -38,7 +55,51 @@ pub fn generate_release_notes( .collect::>(); println!("Found {} issues", issue_titles.len()); + // If there is metadata that already exists, + // and would contain info such as which PR already + // has an entry, then get it and use it for that. + let preexisting_metadata_file = fs::read_to_string(path.join("_release-notes.toml")).ok(); + // Deserializes the file inside the option into the `ReleaseNotes` struct, + // and then transposes / swaps the internal result of that operation to external, + // and returns the error of that result if there is one, + // else we have our preexisting metadata, ready to use. + let preexisting_metadata: Option = preexisting_metadata_file + .as_deref() + .map(toml::from_str) + .transpose()?; + + eprintln!("metadata exists? {}", preexisting_metadata.is_some()); + + let mut new_prs = false; + for (pr, commit, title) in prs { + // If a PR is already included in the release notes, + // then do not generate anything for this PR. + // + // If overwrite_existing is true, then ignore + // if the PRs may have already been generated. + if preexisting_metadata.is_some() && !overwrite_existing { + let preexisting_metadata = preexisting_metadata + .clone() + .expect("that preexisting metadata existed at the _release_notes.toml for this release version"); + let mut pr_already_generated = false; + + for release_note in preexisting_metadata.release_notes { + if release_note.prs.contains(&pr.number) { + pr_already_generated = true; + } + } + + if pr_already_generated { + eprintln!("PR #{} already exists", pr.number); + continue; + } + } + + // If the code has reached this point then that means + // there is new PRs to be recorded. + new_prs = true; + // Slugify the title let title_slug = title .replace(' ', "_") @@ -79,10 +140,6 @@ pub fn generate_release_notes( )); let file_path = path.join(format!("{file_name}.md")); - if file_path.exists() && !overwrite_existing { - // Skip existing files because we don't want to overwrite changes when regenerating - continue; - } let file = std::fs::File::create(&file_path).context(format!("Failed to create {file_path:?}"))?; @@ -106,19 +163,41 @@ pub fn generate_release_notes( ); } - // Write the metadata file - let mut notes_toml = std::fs::File::create(path.join("_release-notes.toml")) - .context("Failed to create _guides.toml")?; - for metadata in notes_metadata { - writeln!(&mut notes_toml, "{metadata}")?; - } - if !create_issues { println!( "No issues were created. If you would like to do so, add the `--create-issues` flag." ); } + eprintln!("new prs? {new_prs}"); + + // Early return if there is no new PRs + // to append to the metadata file. + if !new_prs { + return Ok(()); + } + + let mut notes_toml = if overwrite_existing { + // Replace and overwrite file. + OpenOptions::new() + .write(true) + .truncate(true) + .create(true) + .open(path.join("_release-notes.toml")) + .context("Failed to create _release-notes.toml")? + } else { + // Append to the metadata file, + // creating it if necessary. + OpenOptions::new() + .append(true) + .create(true) + .open(path.join("_release-notes.toml")) + .context("Failed to create _release-notes.toml")? + }; + for metadata in notes_metadata { + writeln!(&mut notes_toml, "{metadata}")?; + } + Ok(()) } @@ -135,7 +214,7 @@ fn generate_metadata_block( title = "{title}" authors = ["{author}",] contributors = [{contributors}] -url = "https://github.com/bevyengine/bevy/pull/{pr_number}" +prs = [{pr_number}] file_name = "{file_name}.md" "#, contributors = contributors @@ -204,7 +283,7 @@ In that PR, please mention this issue with the `Fixes #ISSUE_NUMBER` keyphrase s println!("Would open issue on GitHub:"); println!("Title: {}", issue_title); println!("Body: {}", issue_body); - println!("Labels: {:?}", labels); + println!("Labels: {:?}\n\n", labels); } else { // Open an issue on the `bevy-website` repo let response = client diff --git a/release-content/0.14/migration-guides/_guides.toml b/release-content/0.14/migration-guides/_guides.toml index 2804036c58..764edbaccc 100644 --- a/release-content/0.14/migration-guides/_guides.toml +++ b/release-content/0.14/migration-guides/_guides.toml @@ -1,779 +1,779 @@ -[[guides]] -title = "Overhaul `Color`" -url = "https://github.com/bevyengine/bevy/pull/12163" -areas = ["Color", "Gizmos", "Rendering", "Text", "UI"] -file_name = "12163_Migrate_from_LegacyColor_to_bevy_colorColor.md" - -[[guides]] -title = "Make default behavior for `BackgroundColor` and `BorderColor` more intuitive" -url = "https://github.com/bevyengine/bevy/pull/14017" -areas = ["Rendering", "UI"] -file_name = "14017_Make_default_behavior_for_BackgroundColor_and_BorderColor_.md" - -[[guides]] -title = "Register missing types manually" -url = "https://github.com/bevyengine/bevy/pull/12314" -areas = ["Reflection"] -file_name = "12314_Clean_up_type_registrations.md" - -[[guides]] -title = "`OnEnter` state schedules now run before Startup schedules" -url = "https://github.com/bevyengine/bevy/pull/11426" -areas = ["App", "ECS"] -file_name = "11426_on_enter_startup_states.md" - -[[guides]] -title = "Fix `Node2d` typo" -url = "https://github.com/bevyengine/bevy/pull/12038" -areas = [] -file_name = "12038_fix_some_typos.md" - -[[guides]] -title = "Update to `fixedbitset` 0.5" -url = "https://github.com/bevyengine/bevy/pull/12512" -areas = [] -file_name = "12512_Update_to_fixedbitset_05.md" - -[[guides]] -title = "Move WASM panic handler from `LogPlugin` to `PanicHandlerPlugin`" -url = "https://github.com/bevyengine/bevy/pull/12557" -areas = [] -file_name = "12557_refactor_separate_out_PanicHandlerPlugin.md" - [[guides]] title = "`AnimationClip` now uses UUIDs and `NoOpTypeIdHash` is now `NoOpHash`" -url = "https://github.com/bevyengine/bevy/pull/11707" +prs = ["11707"] areas = ["Animation"] file_name = "11707_Rework_animation_to_be_done_in_two_phases.md" [[guides]] title = "Implement the `AnimationGraph` to blend animations together" -url = "https://github.com/bevyengine/bevy/pull/11989" +prs = ["11989"] areas = ["Animation"] file_name = "11989_Implement_the_AnimationGraph_allowing_for_multiple_animati.md" [[guides]] title = "Multiplying colors by `f32` no longer ignores alpha channel" -url = "https://github.com/bevyengine/bevy/pull/12575" +prs = ["12575"] areas = ["Animation", "Color", "Math", "Rendering"] file_name = "12575_Color_maths_4.md" +[[guides]] +title = "`OnEnter` state schedules now run before Startup schedules" +prs = ["11426"] +areas = ["App", "ECS"] +file_name = "11426_on_enter_startup_states.md" + [[guides]] title = "Separate `SubApp` from `App`" -url = "https://github.com/bevyengine/bevy/pull/9202" +prs = ["9202"] areas = ["App"] file_name = "9202_Refactor_App_and_SubApp_internals_for_better_separation.md" [[guides]] title = "Make `AppExit` more specific about exit reason" -url = "https://github.com/bevyengine/bevy/pull/13022" +prs = ["13022"] areas = ["App"] file_name = "13022_Make_AppExit_more_specific_about_exit_reason.md" [[guides]] title = "Deprecate dynamic plugins" -url = "https://github.com/bevyengine/bevy/pull/13080" +prs = ["13080"] areas = ["App"] file_name = "13080_Deprecate_dynamic_plugins.md" [[guides]] title = "Move state initialization methods to `bevy::state`" -url = "https://github.com/bevyengine/bevy/pull/13637" +prs = ["13637"] areas = ["App", "ECS"] file_name = "13637_Move_state_installation_methods_from_bevy_app_to_bevy_stat.md" [[guides]] title = "Remove the `UpdateAssets` and `AssetEvents` schedules" -url = "https://github.com/bevyengine/bevy/pull/11986" +prs = ["11986"] areas = ["Assets"] file_name = "11986_Remove_the_UpdateAssets_and_AssetEvents_schedules.md" [[guides]] title = "Use `async fn` in traits rather than `BoxedFuture`" -url = "https://github.com/bevyengine/bevy/pull/12550" +prs = ["12550"] areas = ["Assets"] file_name = "12550_Use_asyncfn_in_traits_rather_than_BoxedFuture.md" [[guides]] title = "Add `Ignore` variant to `ProcessResult`" -url = "https://github.com/bevyengine/bevy/pull/12605" +prs = ["12605"] areas = ["Assets"] file_name = "12605_Make_AssetActionIgnore_not_copy_assets_to_imported_assets.md" [[guides]] title = "Removed `Into>` for `Handle`" -url = "https://github.com/bevyengine/bevy/pull/12655" +prs = ["12655"] areas = ["Assets"] file_name = "12655_Removed_IntoAssedIdT_for_HandleT_as_mentioned_in_12600.md" [[guides]] title = "Add `AsyncSeek` trait to `Reader` to be able to seek inside asset loaders" -url = "https://github.com/bevyengine/bevy/pull/12547" +prs = ["12547"] areas = ["Assets"] file_name = "12547_Add_AsyncSeek_trait_to_Reader_to_be_able_to_seek_inside_as.md" [[guides]] title = "Add error info to `LoadState::Failed`" -url = "https://github.com/bevyengine/bevy/pull/12709" +prs = ["12709"] areas = ["Assets"] file_name = "12709_Error_info_has_been_added_to_LoadStateFailed.md" [[guides]] title = "Make `AssetMetaCheck` a field of `AssetPlugin`" -url = "https://github.com/bevyengine/bevy/pull/13177" +prs = ["13177"] areas = ["Assets"] file_name = "13177_Make_AssetMetaCheck_a_field_on_the_asset_plugin.md" [[guides]] title = "Make `LoadContext` use the builder pattern" -url = "https://github.com/bevyengine/bevy/pull/13465" +prs = ["13465"] areas = ["Assets"] file_name = "13465_Make_LoadContext_use_the_builder_pattern_for_loading_depen.md" [[guides]] title = "Use `RenderAssetUsages` to configure gLTF meshes & materials during load" -url = "https://github.com/bevyengine/bevy/pull/12302" +prs = ["12302"] areas = ["Assets", "Rendering"] file_name = "12302_Allow_setting_RenderAssetUsages_for_gLTF_meshes__materials.md" [[guides]] title = "Consolidate `RenderMaterials` and similar into `RenderAssets`, implement `RenderAsset` for destination type" -url = "https://github.com/bevyengine/bevy/pull/12827" +prs = ["12827"] areas = ["Assets", "Rendering"] file_name = "12827_Consolidate_RenderUiMaterials2d_into_RenderAssets.md" [[guides]] title = "Fix leftover references to children when despawning audio entities" -url = "https://github.com/bevyengine/bevy/pull/12407" +prs = ["12407"] areas = ["Audio"] file_name = "12407_Fix_leftover_references_to_children_when_despawning_audio_.md" +[[guides]] +title = "Overhaul `Color`" +prs = ["12163"] +areas = ["Color", "Gizmos", "Rendering", "Text", "UI"] +file_name = "12163_Migrate_from_LegacyColor_to_bevy_colorColor.md" + [[guides]] title = "Move WGSL math constants and color operations from `bevy_pbr` to `bevy_render`" -url = "https://github.com/bevyengine/bevy/pull/13209" +prs = ["13209"] areas = ["Color"] file_name = "13209_move_wgsl_color_operations_from_bevy_pbr_to_bevy_render.md" [[guides]] title = "Remove old color space utilities" -url = "https://github.com/bevyengine/bevy/pull/12105" +prs = ["12105"] areas = ["Color", "Rendering"] file_name = "12105_Made_bevy_color_a_dependency_of_bevy_render.md" [[guides]] title = "Use `LinearRgba` in `ColorAttachment`" -url = "https://github.com/bevyengine/bevy/pull/12116" +prs = ["12116"] areas = ["Color", "Rendering"] file_name = "12116_Port_bevy_core_pipeline_to_LinearRgba.md" [[guides]] title = "Remove `close_on_esc`" -url = "https://github.com/bevyengine/bevy/pull/12859" +prs = ["12859"] areas = ["Dev-Tools"] file_name = "12859_remove_close_on_esc.md" [[guides]] title = "Make `sysinfo` diagnostic plugin optional" -url = "https://github.com/bevyengine/bevy/pull/12164" +prs = ["12164"] areas = ["Diagnostics"] file_name = "12164_Make_sysinfo_diagnostic_plugin_optional.md" [[guides]] title = "Improve `tracing` layer customization" -url = "https://github.com/bevyengine/bevy/pull/13159" +prs = ["13159"] areas = ["Diagnostics"] file_name = "13159_Improve_tracing_layer_customization.md" [[guides]] title = "Generalised ECS reactivity with Observers" -url = "https://github.com/bevyengine/bevy/pull/10839" +prs = ["10839"] areas = ["ECS"] file_name = "10839_Generalised_ECS_reactivity_with_Observers.md" [[guides]] title = "Immediately apply deferred system params in `System::run`" -url = "https://github.com/bevyengine/bevy/pull/11823" +prs = ["11823"] areas = ["ECS"] file_name = "11823_Immediately_apply_deferred_system_params_in_Systemrun.md" [[guides]] title = "Move `Command` and `CommandQueue` into `bevy::ecs::world`" -url = "https://github.com/bevyengine/bevy/pull/12234" +prs = ["12234"] areas = ["ECS"] file_name = "12234_Move_commands_module_into_bevyecsworld.md" [[guides]] title = "Make `Component::Storage` a constant" -url = "https://github.com/bevyengine/bevy/pull/12311" +prs = ["12311"] areas = ["ECS"] file_name = "12311_Remove_ComponentStorage_and_associated_types.md" [[guides]] title = "Don't store `Access` within `QueryState`" -url = "https://github.com/bevyengine/bevy/pull/12474" +prs = ["12474"] areas = ["ECS"] file_name = "12474_Remove_archetype_component_access_from_QueryState.md" [[guides]] title = "Remove `WorldCell`" -url = "https://github.com/bevyengine/bevy/pull/12551" +prs = ["12551"] areas = ["ECS"] file_name = "12551_Remove_WorldCell.md" [[guides]] title = "Return iterator instead of slice for `QueryState::matched_tables` and `QueryState::matches_archtypes`" -url = "https://github.com/bevyengine/bevy/pull/12476" +prs = ["12476"] areas = ["ECS"] file_name = "12476_Store_only_the_IDs_needed_for_Query_iteration.md" [[guides]] title = "Remove system stepping from default features" -url = "https://github.com/bevyengine/bevy/pull/12847" +prs = ["12847"] areas = ["ECS"] file_name = "12847_Remove_stepping_from_default_features.md" [[guides]] title = "Optimize event updates and virtual time" -url = "https://github.com/bevyengine/bevy/pull/12936" +prs = ["12936"] areas = ["ECS"] file_name = "12936_Optimize_Event_Updates.md" [[guides]] title = "Make `SystemParam::new_archetype` and `QueryState::new_archetype` unsafe" -url = "https://github.com/bevyengine/bevy/pull/13044" +prs = ["13044"] areas = ["ECS"] file_name = "13044_Make_SystemParamnew_archetype_and_QueryStatenew_archetype_.md" [[guides]] title = "Better `SystemId` and `Entity` conversion" -url = "https://github.com/bevyengine/bevy/pull/13090" +prs = ["13090"] areas = ["ECS"] file_name = "13090_Better_SystemId_to_Entity_conversions.md" [[guides]] title = "Make `NextState` an enum" -url = "https://github.com/bevyengine/bevy/pull/11426" +prs = ["11426"] areas = ["ECS"] file_name = "11426_Computed_State__Sub_States.md" [[guides]] title = "Separate states from core ECS" -url = "https://github.com/bevyengine/bevy/pull/13216" +prs = ["13216"] areas = ["ECS"] file_name = "13216_Separate_state_crate.md" [[guides]] title = "Constrain `WorldQuery::get_state()` to only accept `Components`" -url = "https://github.com/bevyengine/bevy/pull/13343" +prs = ["13343"] areas = ["ECS"] file_name = "13343_constrain_WorldQueryget_state_to_only_use_Components.md" [[guides]] title = "Unify state transition names to `exited` and `entered`" -url = "https://github.com/bevyengine/bevy/pull/13594" +prs = ["13594"] areas = ["ECS"] file_name = "13594_Unify_transition_names_to_exited_and_entered.md" [[guides]] title = "Make `apply_state_transition` private" -url = "https://github.com/bevyengine/bevy/pull/13626" +prs = ["13626"] areas = ["ECS"] file_name = "13626_Combine_transition_systems_of_Substates.md" [[guides]] title = "Replace `FromWorld` requirement with `FromReflect` on `ReflectResource`" -url = "https://github.com/bevyengine/bevy/pull/12136" +prs = ["12136"] areas = ["ECS", "Reflection"] file_name = "12136_Replace_FromWorld_requirement_on_ReflectResource_and_refle.md" [[guides]] title = "Make `ReflectComponentFns` and `ReflectBundleFns` methods work with `EntityMut`" -url = "https://github.com/bevyengine/bevy/pull/12895" +prs = ["12895"] areas = ["ECS", "Reflection"] file_name = "12895_Make_some_ReflectComponentReflectBundle_methods_work_with_.md" [[guides]] title = "Require `TypeRegistry` in `ReflectBundle::insert()`" -url = "https://github.com/bevyengine/bevy/pull/12499" +prs = ["12499"] areas = ["ECS", "Reflection"] file_name = "12499_Make_from_reflect_or_world_also_try_ReflectDefault_and_imp.md" [[guides]] title = "Rename `multi-threaded` feature to `multi_threaded`" -url = "https://github.com/bevyengine/bevy/pull/12997" +prs = ["12997"] areas = ["ECS", "Tasks"] file_name = "12997_multi_threaded_feature_rename.md" [[guides]] title = "Moves `intern` and `label` modules from `bevy::utils` to `bevy::ecs`" -url = "https://github.com/bevyengine/bevy/pull/12772" +prs = ["12772"] areas = ["ECS", "Utils"] file_name = "12772_Moves_intern_and_label_modules_into_bevy_ecs.md" [[guides]] title = "Gizmo line joints" -url = "https://github.com/bevyengine/bevy/pull/12252" +prs = ["12252"] areas = ["Gizmos"] file_name = "12252_Gizmo_line_joints.md" [[guides]] title = "Gizmo line styles" -url = "https://github.com/bevyengine/bevy/pull/12394" +prs = ["12394"] areas = ["Gizmos"] file_name = "12394_Gizmo_line_styles.md" [[guides]] title = "Rename `segments()` methods to `resolution()`" -url = "https://github.com/bevyengine/bevy/pull/13438" +prs = ["13438"] areas = ["Gizmos"] file_name = "13438_Inconsistent_segmentsresolution_naming.md" [[guides]] title = "Make gizmos take primitives as a reference" -url = "https://github.com/bevyengine/bevy/pull/13534" +prs = ["13534"] areas = ["Gizmos"] file_name = "13534_Make_gizmos_take_primitives_by_ref.md" [[guides]] title = "More gizmos builders" -url = "https://github.com/bevyengine/bevy/pull/13261" +prs = ["13261"] areas = ["Gizmos"] file_name = "13261_More_gizmos_builders.md" +[[guides]] +title = "Contextually clearing gizmos" +prs = ["10973"] +areas = ["Gizmos"] +file_name = "10973_Contextually_clearing_gizmos.md" + [[guides]] title = "Rename touchpad input to gesture" -url = "https://github.com/bevyengine/bevy/pull/13660" +prs = ["13660"] areas = ["Input"] file_name = "13660_rename_touchpad_to_gesture_and_add_new_gestures.md" [[guides]] title = "Deprecate `ReceivedCharacter`" -url = "https://github.com/bevyengine/bevy/pull/12868" +prs = ["12868"] areas = ["Input", "Windowing"] file_name = "12868_Deprecate_ReceivedCharacter.md" [[guides]] title = "Add `WinitEvent::KeyboardFocusLost`" -url = "https://github.com/bevyengine/bevy/pull/13678" +prs = ["13678"] areas = ["Input", "Windowing"] file_name = "13678_flush_key_input_cache_when_Bevy_loses_focus_Adopted.md" +[[guides]] +title = "Separating Finite and Infinite 3d Planes" +prs = ["12426"] +areas = ["Math", "Rendering"] +file_name = "12426_separating_finite_and_infinite_3d_planes.md" + [[guides]] title = "Move direction types out of `bevy::math::primitives`" -url = "https://github.com/bevyengine/bevy/pull/12018" +prs = ["12018"] areas = ["Math"] file_name = "12018_Add_Direction3dA_and_move_direction_types_out_of_primitive.md" [[guides]] title = "Rename `Direction2d/3d` to `Dir2/3`" -url = "https://github.com/bevyengine/bevy/pull/12189" +prs = ["12189"] areas = ["Math"] file_name = "12189_Rename_Direction2d3d_to_Dir23.md" [[guides]] title = "Make cardinal splines include endpoints" -url = "https://github.com/bevyengine/bevy/pull/12574" +prs = ["12574"] areas = ["Math"] file_name = "12574_Make_cardinal_splines_include_endpoints.md" [[guides]] title = "Replace `Point` with `VectorSpace`" -url = "https://github.com/bevyengine/bevy/pull/12747" +prs = ["12747"] areas = ["Math"] file_name = "12747_Move_Point_out_of_cubic_splines_module_and_expand_it.md" [[guides]] title = "UV-mapping change for `Triangle2d`" -url = "https://github.com/bevyengine/bevy/pull/12686" +prs = ["12686"] areas = ["Math"] file_name = "12686_Meshing_for_Triangle3d_primitive.md" [[guides]] title = "Use `Vec3A` for 3D bounding volumes and raycasts" -url = "https://github.com/bevyengine/bevy/pull/13087" +prs = ["13087"] areas = ["Math"] file_name = "13087_Use_Vec3A_for_3D_bounding_volumes_and_raycasts.md" [[guides]] title = "Update `glam` to 0.27" -url = "https://github.com/bevyengine/bevy/pull/12757" +prs = ["12757"] areas = ["Math"] file_name = "12757_Update_glam_version_requirement_from_025_to_027.md" [[guides]] title = "Common `MeshBuilder` trait" -url = "https://github.com/bevyengine/bevy/pull/13411" +prs = ["13411"] areas = ["Math", "Rendering"] file_name = "13411_Common_MeshBuilder_trait.md" [[guides]] title = "Add angle range to `TorusMeshBuilder`" -url = "https://github.com/bevyengine/bevy/pull/13605" +prs = ["13605"] areas = ["Math", "Rendering"] file_name = "13605_Additional_options_to_mesh_primitives.md" [[guides]] title = "Add subdivisions to `PlaneMeshBuilder`" -url = "https://github.com/bevyengine/bevy/pull/13580" +prs = ["13580"] areas = ["Math", "Rendering"] file_name = "13580_Add_subdivisions_to_PlaneMeshBuilder.md" [[guides]] title = "Make `Transform::rotate_axis` and `Transform::rotate_local_axis` use `Dir3`" -url = "https://github.com/bevyengine/bevy/pull/12986" +prs = ["12986"] areas = ["Math", "Transform"] file_name = "12986_Make_Transformrotate_axis_and_Transformrotate_local_axis_u.md" [[guides]] title = "Use `Dir3` for local axis methods in `GlobalTransform`" -url = "https://github.com/bevyengine/bevy/pull/13264" +prs = ["13264"] areas = ["Math", "Transform"] file_name = "13264_Use_Dir3_for_local_axis_methods_in_GlobalTransform.md" [[guides]] title = "Fix `Ord` and `PartialOrd` differing for `FloatOrd`" -url = "https://github.com/bevyengine/bevy/pull/12711" +prs = ["12711"] areas = ["Math", "Utils"] file_name = "12711_Fix_Ord_and_PartialOrd_differing_for_FloatOrd_and_optimize.md" [[guides]] title = "Move `FloatOrd` into `bevy::math`" -url = "https://github.com/bevyengine/bevy/pull/12732" +prs = ["12732"] areas = ["Math", "Utils"] file_name = "12732_Move_FloatOrd_into_bevy_math.md" +[[guides]] +title = "Register missing types manually" +prs = ["12314"] +areas = ["Reflection"] +file_name = "12314_Clean_up_type_registrations.md" + [[guides]] title = "Change `ReflectSerialize` trait bounds" -url = "https://github.com/bevyengine/bevy/pull/12024" +prs = ["12024"] areas = ["Reflection"] file_name = "12024_reflect_treat_proxy_types_correctly_when_serializing.md" [[guides]] title = "Recursive registration of types" -url = "https://github.com/bevyengine/bevy/pull/5781" +prs = ["5781"] areas = ["Reflection"] file_name = "5781_bevy_reflect_Recursive_registration.md" [[guides]] title = "Rename `UntypedReflectDeserializer` to `ReflectDeserializer`" -url = "https://github.com/bevyengine/bevy/pull/12721" +prs = ["12721"] areas = ["Reflection"] file_name = "12721_bevy_reflect_Rename_UntypedReflectDeserializer_to_ReflectD.md" [[guides]] title = "Implement `Reflect` for `Result` as an enum" -url = "https://github.com/bevyengine/bevy/pull/13182" +prs = ["13182"] areas = ["Reflection"] file_name = "13182_Implement_Reflect_for_ResultT_E_as_enum.md" [[guides]] title = "Serialize scene with `&TypeRegistry` and rename `serialize_ron()` to `serialize()`" -url = "https://github.com/bevyengine/bevy/pull/12715" +prs = ["12715"] areas = ["Reflection", "Scenes"] file_name = "12715_Fix_TypeRegistry_use_in_dynamic_scene.md" +[[guides]] +title = "Make default behavior for `BackgroundColor` and `BorderColor` more intuitive" +prs = ["14017"] +areas = ["Rendering", "UI"] +file_name = "14017_Make_default_behavior_for_BackgroundColor_and_BorderColor_.md" + [[guides]] title = "Rename `Camera3dBundle::dither` to `deband_dither`" -url = "https://github.com/bevyengine/bevy/pull/11939" +prs = ["11939"] areas = ["Rendering"] file_name = "11939_rename_Camera3dBundles_dither_field_to_deband_dither_to_al.md" [[guides]] title = "Rename `affine_to_square()` to `affine3_to_square()`" -url = "https://github.com/bevyengine/bevy/pull/11904" +prs = ["11904"] areas = ["Rendering"] file_name = "11904_Add_support_for_KHR_texture_transform.md" [[guides]] title = "Move `AlphaMode` into `bevy::render`" -url = "https://github.com/bevyengine/bevy/pull/12012" +prs = ["12012"] areas = ["Rendering"] file_name = "12012_Move_AlphaMode_into_bevy_render.md" [[guides]] title = "Use `UVec2` when working with texture dimensions" -url = "https://github.com/bevyengine/bevy/pull/11698" +prs = ["11698"] areas = ["Rendering"] file_name = "11698_Prefer_UVec2_when_working_with_texture_dimensions.md" [[guides]] title = "Fix `CameraProjectionPlugin` not implementing `Plugin` in some cases" -url = "https://github.com/bevyengine/bevy/pull/11766" +prs = ["11766"] areas = ["Rendering"] file_name = "11766_Fix_CameraProjectionPlugin_not_implementing_Plugin_in_some.md" [[guides]] title = "Replace `random1D()` with `rand_f()` shader function" -url = "https://github.com/bevyengine/bevy/pull/11956" +prs = ["11956"] areas = ["Rendering"] file_name = "11956_Add_random_shader_utils_fix_cluster_debug_visualization.md" [[guides]] title = "Intern mesh vertex buffer layouts" -url = "https://github.com/bevyengine/bevy/pull/12216" +prs = ["12216"] areas = ["Rendering"] file_name = "12216_Intern_mesh_vertex_buffer_layouts_so_that_we_dont_have_to_.md" [[guides]] title = "Make `GpuArrayBufferIndex::index` a u32" -url = "https://github.com/bevyengine/bevy/pull/12250" +prs = ["12250"] areas = ["Rendering"] file_name = "12250_Batching_replace_GpuArrayBufferIndexindex_with_a_u32.md" [[guides]] title = "Allow disabling shadows through `MaterialPlugin`" -url = "https://github.com/bevyengine/bevy/pull/12538" +prs = ["12538"] areas = ["Rendering"] file_name = "12538_Add_setting_to_enabledisable_shadows_to_MaterialPlugin.md" [[guides]] title = "Remove `SpritePipeline::COLORED`" -url = "https://github.com/bevyengine/bevy/pull/12559" +prs = ["12559"] areas = ["Rendering"] file_name = "12559_Remove_needless_color_specializaion_for_SpritePipeline.md" [[guides]] title = "Sorted and binned render phase items, resources, and non-meshes" -url = "https://github.com/bevyengine/bevy/pull/12453" +prs = ["12453"] areas = ["Rendering"] file_name = "12453_13277_14029_sorted_and_binned_render_phase_items.md" [[guides]] title = "GPU frustum culling" -url = "https://github.com/bevyengine/bevy/pull/12889" +prs = ["12889"] areas = ["Rendering"] file_name = "12889_Implement_GPU_frustum_culling.md" [[guides]] title = "Remove `DeterministicRenderingConfig`" -url = "https://github.com/bevyengine/bevy/pull/12811" +prs = ["12811"] areas = ["Rendering"] file_name = "12811_remove_DeterministicRenderingConfig.md" [[guides]] title = "Optimize `queue_material_meshes` and remove some bit manipulation" -url = "https://github.com/bevyengine/bevy/pull/12791" +prs = ["12791"] areas = ["Rendering"] file_name = "12791_Microoptimize_queue_material_meshes_primarily_to_remove_bi.md" [[guides]] title = "Disable `RAY_QUERY` and `RAY_TRACING_ACCELERATION_STRUCTURE` by default" -url = "https://github.com/bevyengine/bevy/pull/12862" +prs = ["12862"] areas = ["Rendering"] file_name = "12862_Disable_RAY_QUERY_and_RAY_TRACING_ACCELERATION_STRUCTURE_b.md" [[guides]] title = "Upload previous frame's `inverse_view` to GPU" -url = "https://github.com/bevyengine/bevy/pull/12902" +prs = ["12902"] areas = ["Rendering"] file_name = "12902_Add_previous_view_uniformsinverse_view.md" [[guides]] title = "Generate `MeshUniform`s on the GPU when available." -url = "https://github.com/bevyengine/bevy/pull/12773" +prs = ["12773"] areas = ["Rendering"] file_name = "12773_Generate_MeshUniforms_on_the_GPU_via_compute_shader_where_.md" [[guides]] title = "Add texture coord flipping to `StandardMaterial`" -url = "https://github.com/bevyengine/bevy/pull/12917" +prs = ["12917"] areas = ["Rendering"] file_name = "12917_flipping_texture_coords_methods_has_been_added_to_the_Stan.md" [[guides]] title = "Rename `ShadowFilteringMethod`'s `Castano13` and `Jimenez14` variants" -url = "https://github.com/bevyengine/bevy/pull/12910" +prs = ["12910"] areas = ["Rendering"] file_name = "12910_Implement_percentagecloser_filtering_PCF_for_point_lights.md" [[guides]] title = "Store lists of `VisibleEntities` separately" -url = "https://github.com/bevyengine/bevy/pull/12582" +prs = ["12582"] areas = ["Rendering"] file_name = "12582_Divide_the_single_VisibleEntities_list_into_separate_lists.md" [[guides]] title = "Make `Text` require `SpriteSource`" -url = "https://github.com/bevyengine/bevy/pull/12945" +prs = ["12945"] areas = ["Rendering"] file_name = "12945_Fix_rendering_of_sprites_text_and_meshlets_after_12582.md" [[guides]] title = "Expose `desired_maximum_frame_latency`" -url = "https://github.com/bevyengine/bevy/pull/12954" +prs = ["12954"] areas = ["Rendering"] file_name = "12954_Expose_desired_maximum_frame_latency_through_window_creati.md" [[guides]] title = "Merge `VisibilitySystems` frusta variants" -url = "https://github.com/bevyengine/bevy/pull/11808" +prs = ["11808"] areas = ["Rendering"] file_name = "11808_Fix_CameraProjection_panic_and_improve_CameraProjectionPlu.md" [[guides]] title = "Expand color grading" -url = "https://github.com/bevyengine/bevy/pull/13121" +prs = ["13121"] areas = ["Rendering"] file_name = "13121_Implement_filmic_color_grading.md" [[guides]] title = "Rename `BufferVec` to `RawBufferVec`" -url = "https://github.com/bevyengine/bevy/pull/13199" +prs = ["13199"] areas = ["Rendering"] file_name = "13199_Add_BufferVec_an_higherperformance_alternative_to_StorageB.md" [[guides]] title = "Implement clearcoat" -url = "https://github.com/bevyengine/bevy/pull/13031" +prs = ["13031"] areas = ["Rendering"] file_name = "13031_Implement_clearcoat_per_the_Filament_and_the_KHR_materials.md" [[guides]] title = "Split `Node2d::MainPass`" -url = "https://github.com/bevyengine/bevy/pull/12982" +prs = ["12982"] areas = ["Rendering"] file_name = "12982_Clean_up_2d_render_phases.md" [[guides]] title = "Remove limit on `RenderLayers`" -url = "https://github.com/bevyengine/bevy/pull/13317" +prs = ["13317"] areas = ["Rendering"] file_name = "13317_12502_Remove_limit_on_RenderLayers.md" [[guides]] title = "Fix astronomic emissive colors required for bloom" -url = "https://github.com/bevyengine/bevy/pull/13350" +prs = ["13350"] areas = ["Rendering"] file_name = "13350_Add_emissive_exposure_weight_to_the_StandardMaterial.md" [[guides]] title = "More idiomatic `TextureAtlasBuilder`" -url = "https://github.com/bevyengine/bevy/pull/13238" +prs = ["13238"] areas = ["Rendering"] file_name = "13238_More_idiomatic_texture_atlas_builder.md" [[guides]] title = "Normalise matrix naming" -url = "https://github.com/bevyengine/bevy/pull/13489" +prs = ["13489"] areas = ["Rendering"] file_name = "13489_Normalise_matrix_naming.md" [[guides]] title = "Rename \"point light\" to \"clusterable object\" in cluster contexts" -url = "https://github.com/bevyengine/bevy/pull/13654" +prs = ["13654"] areas = ["Rendering"] file_name = "13654_Rename_point_light_to_clusterable_object_in_cluster_contex.md" [[guides]] title = "Make `Mesh::merge()` take a reference of `Mesh`" -url = "https://github.com/bevyengine/bevy/pull/13710" +prs = ["13710"] areas = ["Rendering"] file_name = "13710_Made_Meshmerge_take_a_reference_of_Mesh.md" [[guides]] title = "Store `ClearColorConfig` instead of `LoadOp` in `CameraOutputMode`" -url = "https://github.com/bevyengine/bevy/pull/13419" +prs = ["13419"] areas = ["Rendering"] file_name = "13419_Allow_mix_of_hdr_and_nonhdr_cameras_to_same_render_target.md" [[guides]] title = "`wgpu` 0.20" -url = "https://github.com/bevyengine/bevy/pull/13186" +prs = ["13186"] areas = ["Rendering"] file_name = "13186_Wgpu_020.md" [[guides]] title = "Deprecate `SpriteSheetBundle` and `AtlasImageBundle`" -url = "https://github.com/bevyengine/bevy/pull/12218" +prs = ["12218"] areas = ["Rendering", "UI"] file_name = "12218_Deprecate_SpriteSheetBundle_and_AtlasImageBundle.md" [[guides]] title = "Decouple `BackgroundColor` from `UiImage`" -url = "https://github.com/bevyengine/bevy/pull/11165" +prs = ["11165"] areas = ["Rendering", "UI"] file_name = "11165_Decouple_BackgroundColor_from_UiImage.md" [[guides]] title = "Remove generic camera from `extract_default_ui_camera_view()` system" -url = "https://github.com/bevyengine/bevy/pull/13462" +prs = ["13462"] areas = ["Rendering", "UI"] file_name = "13462_Fix_UI_elements_randomly_not_appearing_after_13277.md" [[guides]] title = "Rename `need_new_surfaces()` system to `need_surface_configuration()`" -url = "https://github.com/bevyengine/bevy/pull/12055" +prs = ["12055"] areas = ["Rendering", "Windowing"] file_name = "12055_configure_surface_needs_to_be_on_the_main_thread_on_iOS.md" [[guides]] title = "Require windowing backends to store windows in `WindowWrapper`" -url = "https://github.com/bevyengine/bevy/pull/12978" +prs = ["12978"] areas = ["Rendering", "Windowing"] file_name = "12978_Introduce_a_WindowWrapper_to_extend_the_lifetime_of_the_wi.md" [[guides]] title = "Add an index argument to parallel iteration helpers" -url = "https://github.com/bevyengine/bevy/pull/12169" +prs = ["12169"] areas = ["Tasks"] file_name = "12169_Add_an_index_argument_to_parallel_iteration_helpers_in_bev.md" [[guides]] title = "Fix spawning `NodeBundle` destroying previous ones" -url = "https://github.com/bevyengine/bevy/pull/12698" +prs = ["12698"] areas = ["UI"] file_name = "12698_Restore_pre_0131_Root_Node_Layout_behavior.md" [[guides]] title = "Rename `Rect::inset()` to `inflate()`" -url = "https://github.com/bevyengine/bevy/pull/13452" +prs = ["13452"] areas = ["UI"] file_name = "13452_Rename_Rect_inset_method_to_inflate.md" [[guides]] title = "Updates default font size to 24px" -url = "https://github.com/bevyengine/bevy/pull/13603" +prs = ["13603"] areas = ["UI"] file_name = "13603_Updates_default_Text_font_size_to_24px.md" [[guides]] title = "Disentangle `bevy::utils` / `bevy::core`'s re-exported crates" -url = "https://github.com/bevyengine/bevy/pull/12313" +prs = ["12313"] areas = ["Utils"] file_name = "12313_Disentangle_bevy_utilsbevy_cores_reexported_dependencies.md" [[guides]] title = "Re-add `Window::fit_canvas_to_parent`" -url = "https://github.com/bevyengine/bevy/pull/11278" +prs = ["11278"] areas = ["Windowing"] file_name = "11278_Fix_fit_canvas_to_parent.md" [[guides]] title = "Remove window from `WinitWindows` when it is closed" -url = "https://github.com/bevyengine/bevy/pull/12749" +prs = ["12749"] areas = ["Windowing"] file_name = "12749_Clean_up_WinitWindowsremove_window.md" [[guides]] title = "Make window close the frame after it is requested" -url = "https://github.com/bevyengine/bevy/pull/13236" +prs = ["13236"] areas = ["Windowing"] file_name = "13236_Ensure_clean_exit.md" [[guides]] title = "Upgrade to `winit` 0.30" -url = "https://github.com/bevyengine/bevy/pull/13366" +prs = ["13366"] areas = ["Windowing"] file_name = "13366_fix_upgrade_to_winit_v030.md" [[guides]] -title = "Separating Finite and Infinite 3d Planes" -url = "https://github.com/bevyengine/bevy/pull/12426" -areas = ["Math", "Rendering"] -file_name = "12426_separating_finite_and_infinite_3d_planes.md" +title = "Fix `Node2d` typo" +prs = ["12038"] +areas = [] +file_name = "12038_fix_some_typos.md" [[guides]] -title = "Contextually clearing gizmos" -url = "https://github.com/bevyengine/bevy/pull/10973" -areas = ["Gizmos"] -file_name = "10973_Contextually_clearing_gizmos.md" +title = "Update to `fixedbitset` 0.5" +prs = ["12512"] +areas = [] +file_name = "12512_Update_to_fixedbitset_05.md" + +[[guides]] +title = "Move WASM panic handler from `LogPlugin` to `PanicHandlerPlugin`" +prs = ["12557"] +areas = [] +file_name = "12557_refactor_separate_out_PanicHandlerPlugin.md" diff --git a/release-content/0.14/release-notes/12792_Implement_Auto_Exposure_plugin.md b/release-content/0.14/release-notes/12792_Implement_Auto_Exposure_plugin.md index 7d5d40bf04..2fd1fb1973 100644 --- a/release-content/0.14/release-notes/12792_Implement_Auto_Exposure_plugin.md +++ b/release-content/0.14/release-notes/12792_Implement_Auto_Exposure_plugin.md @@ -1,4 +1,4 @@ -Since **Bevy 0.13**, you can [configure the the EV100 of a camera](/news/bevy-0-13/#camera-exposure), which allows you to adjust the exposure of the camera in a physically based way. This also allows you to dynamically change the exposure values for various effects. However, this is a manual process and requires you to adjust the exposure values yourself. +Since **Bevy 0.13**, you can [configure the EV100 of a camera](/news/bevy-0-13/#camera-exposure), which allows you to adjust the exposure of the camera in a physically based way. This also allows you to dynamically change the exposure values for various effects. However, this is a manual process and requires you to adjust the exposure values yourself. **Bevy 0.14** introduces **Auto Exposure**, which automatically adjusts the exposure of your camera based on the brightness of the scene. This can be useful when you want to create the feeling of a very high dynamic range, since your eyes also adjust to large changes in brightness. Note that this is not a replacement for hand-tuning the exposure values, rather an additional tool that you can use to create dramatic effects when brightness changes rapidly. Check out this video recorded from the [example](https://github.com/bevyengine/bevy/tree/v0.14.0/examples/3d/auto_exposure.rs) to see it in action! diff --git a/release-content/0.14/release-notes/_release-notes.toml b/release-content/0.14/release-notes/_release-notes.toml index 3ed3fe90de..f6dd2fe497 100644 --- a/release-content/0.14/release-notes/_release-notes.toml +++ b/release-content/0.14/release-notes/_release-notes.toml @@ -1,103 +1,103 @@ [[release_notes]] title = "Virtual Geometry (Experimental)" authors = ["@JMS55", "@atlv24", "@zeux", "@ricky26"] -url = "https://github.com/bevyengine/bevy/pull/10164" +prs = ["10164"] file_name = "10164_Meshlet_rendering_initial_feature.md" [[release_notes]] title = "Sharp Screen-Space Reflections" authors = ["@pcwalton"] -url = "https://github.com/bevyengine/bevy/pull/13418" +prs = ["13418"] file_name = "13418_Implement_optin_sharp_screenspace_reflections_for_the_defe.md" [[release_notes]] title = "Volumetric Fog and Volumetric Lighting (light shafts / god rays)" authors = ["@pcwalton"] -url = "https://github.com/bevyengine/bevy/pull/13057" +prs = ["13057"] file_name = "13057_Implement_volumetric_fog_and_volumetric_lighting_also_know.md" [[release_notes]] title = "Per-Object Motion Blur" authors = ["@aevyrie", "@torsteingrindvik"] -url = "https://github.com/bevyengine/bevy/pull/9924" +prs = ["9924"] file_name = "9924_PerObject_Motion_Blur.md" [[release_notes]] title = "Filmic Color Grading" authors = ["@pcwalton"] -url = "https://github.com/bevyengine/bevy/pull/13121" +prs = ["13121"] file_name = "13121_Implement_filmic_color_grading.md" [[release_notes]] title = "Auto Exposure" authors = ["@Kurble", "@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/12792" +prs = ["12792"] file_name = "12792_Implement_Auto_Exposure_plugin.md" [[release_notes]] title = "Fast Depth of Field" authors = ["@pcwalton", "@alice-i-cecile", "@Kurble"] -url = "https://github.com/bevyengine/bevy/pull/13009" +prs = ["13009"] file_name = "13009_Implement_fast_depth_of_field_as_a_postprocessing_effect.md" [[release_notes]] title = "PBR Anisotropy" authors = ["@pcwalton"] -url = "https://github.com/bevyengine/bevy/pull/13450" +prs = ["13450"] file_name = "13450_Implement_PBR_anisotropy_per_KHR_materials_anisotropy.md" [[release_notes]] title = "Percentage-Closer Filtering (PCF) for Point Lights" authors = ["@pcwalton"] -url = "https://github.com/bevyengine/bevy/pull/12910" +prs = ["12910"] file_name = "12910_Implement_percentagecloser_filtering_PCF_for_point_lights.md" [[release_notes]] title = "Subpixel Morphological Antialiasing (SMAA)" authors = ["@pcwalton", "@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/13423" +prs = ["13423"] file_name = "13423_Implement_subpixel_morphological_antialiasing_or_SMAA.md" [[release_notes]] title = "Visibility Ranges (hierarchical levels of detail / HLODs)" authors = ["@pcwalton", "@cart"] -url = "https://github.com/bevyengine/bevy/pull/12916" +prs = ["12916"] file_name = "12916_Implement_visibility_ranges_also_known_as_hierarchical_lev.md" [[release_notes]] title = "ECS Hooks and Observers" authors = ["@james-j-obrien", "@cart"] -url = "https://github.com/bevyengine/bevy/pull/10839" +prs = ["10839"] file_name = "10756_hooks_and_observers.md" [[release_notes]] title = "glTF KHR_texture_transform Support" authors = ["@janhohenheim", "@yrns", "@Kanabenki"] -url = "https://github.com/bevyengine/bevy/pull/11904" +prs = ["11904"] file_name = "11904_Add_support_for_KHR_texture_transform.md" [[release_notes]] title = "UI Node Border Radius" authors = ["@chompaa", "@pablo-lua", "@alice-i-cecile", "@bushrat011899"] -url = "https://github.com/bevyengine/bevy/pull/12500" +prs = ["12500"] file_name = "12500_Add_border_radius_to_UI_nodes_adopted.md" [[release_notes]] title = "Animation Blending with the `AnimationGraph`" authors = ["@pcwalton", "@rparrett", "@james7132"] -url = "https://github.com/bevyengine/bevy/pull/11989" +prs = ["11989"] file_name = "11989_Implement_the_AnimationGraph_allowing_for_multiple_animati.md" [[release_notes]] title = "Improved Color API" authors = ["@viridia", "@mockersf"] -url = "https://github.com/bevyengine/bevy/pull/12013" +prs = ["12013"] file_name = "12013_Upstreaming_bevy_color.md" [[release_notes]] title = "Extruded Shapes" authors = ["@lynn-lumen"] -url = "https://github.com/bevyengine/bevy/pull/13270" +prs = ["13270"] file_name = "13270_Extrusion.md" [[release_notes]] @@ -109,109 +109,109 @@ authors = [ "@solis-lumine-vorago", "@alice-i-cecile", ] -url = "https://github.com/bevyengine/bevy/pull/12211" +prs = ["12211"] file_name = "New_gizmos_types.md" [[release_notes]] title = "Gizmo Line Styles and Joints" authors = ["@lynn-lumen"] -url = "https://github.com/bevyengine/bevy/pull/12394" +prs = ["12394"] file_name = "12394_Gizmo_line_styles.md" [[release_notes]] title = "UI Node Outline Gizmos" authors = ["@pablo-lua", "@nicopap", "@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/11237" +prs = ["11237"] file_name = "11237_Add_a_gizmobased_overlay_to_show_UI_node_outlines_Adopted.md" [[release_notes]] title = "Contextually Clearing Gizmos" authors = ["@Aceeri"] -url = "https://github.com/bevyengine/bevy/pull/10973" +prs = ["10973"] file_name = "10973_Contextually_clearing_gizmos.md" [[release_notes]] title = "Query Joins" authors = ["@hymm"] -url = "https://github.com/bevyengine/bevy/pull/11535" +prs = ["11535"] file_name = "11535_Query_Joins.md" [[release_notes]] title = "Computed States & Sub-States" authors = ["@lee-orr", "@marcelchampagne", "@MiniaczQ", "@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/11426" +prs = ["11426"] file_name = "11426_Computed_States__Sub_States.md" [[release_notes]] title = "State Scoped Entities" authors = ["@MiniaczQ", "@alice-i-cecile", "@mockersf"] -url = "https://github.com/bevyengine/bevy/pull/13649" +prs = ["13649"] file_name = "13649_State_Scoped_Entities.md" [[release_notes]] title = "State Identity Transitions" authors = ["@MiniaczQ", "@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/13579" +prs = ["13579"] file_name = "13579_State_Identity_Transitions.md" [[release_notes]] title = "GPU Frustum Culling" authors = ["@pcwalton"] -url = "https://github.com/bevyengine/bevy/pull/12889" +prs = ["12889"] file_name = "12889_Implement_GPU_frustum_culling.md" [[release_notes]] title = "World Command Queue" authors = ["@james7132", "@james-j-obrien"] -url = "https://github.com/bevyengine/bevy/pull/11823" +prs = ["11823"] file_name = "11823_Immediately_apply_deferred_system_params_in_Systemrun.md" [[release_notes]] title = "Reduced Multi-Threaded Execution Overhead" authors = ["@chescock", "@james7132"] -url = "https://github.com/bevyengine/bevy/pull/11906" +prs = ["11906"] file_name = "11906_Run_the_multithreaded_executor_at_the_end_of_each_system_t.md" [[release_notes]] title = "Decouple `BackgroundColor` from `UiImage`" authors = ["@benfrankel"] -url = "https://github.com/bevyengine/bevy/pull/11165" +prs = ["11165"] file_name = "11165_Decouple_BackgroundColor_from_UiImage.md" [[release_notes]] title = "Combined WinitEvent" authors = ["@UkoeHB"] -url = "https://github.com/bevyengine/bevy/pull/12100" +prs = ["12100"] file_name = "12100_Add_WinitEvent_aggregate_event_for_synchronized_window_eve.md" [[release_notes]] title = "Recursive Reflect Registration" authors = ["@MrGVSV", "@soqb", "@cart", "@james7132"] -url = "https://github.com/bevyengine/bevy/pull/5781" +prs = ["5781"] file_name = "5781_bevy_reflect_Recursive_registration.md" [[release_notes]] title = "`Rot2` Type for 2D Rotations" authors = ["@Jondolf", "@IQuick143", "@tguichaoua"] -url = "https://github.com/bevyengine/bevy/pull/11658" +prs = ["11658"] file_name = "11658_Add_Rotation2d.md" [[release_notes]] title = "Alignment API for Transforms" authors = ["@mweatherley"] -url = "https://github.com/bevyengine/bevy/pull/12187" +prs = ["12187"] file_name = "12187_Alignment_API_for_Transforms.md" [[release_notes]] title = "Random Sampling of Shapes and Directions" authors = ["@13ros27", "@mweatherley", "@lynn-lumen"] -url = "https://github.com/bevyengine/bevy/pull/12484" +prs = ["12484"] file_name = "12484_Uniform_point_sampling_methods_for_some_primitive_shapes.md" [[release_notes]] title = "Tools for Profiling GPU Performance" authors = ["@LeshaInc"] -url = "https://github.com/bevyengine/bevy/pull/9135" +prs = ["9135"] file_name = "9135_Add_pipeline_statistics.md" [[release_notes]] @@ -225,7 +225,7 @@ authors = [ "@aristaeus", "@mweatherley", ] -url = "https://github.com/bevyengine/bevy/pull/12508" +prs = ["12508"] file_name = "new_math_primitives.md" [[release_notes]] @@ -238,131 +238,131 @@ authors = [ "@IQuick143", "@alice-i-cecile", ] -url = "https://github.com/bevyengine/bevy/pull/12747" +prs = ["12747"] file_name = "12747_Move_Point_out_of_cubic_splines_module_and_expand_it.md" [[release_notes]] title = "2D Mesh Wireframes" authors = ["@msvbg", "@IceSentry"] -url = "https://github.com/bevyengine/bevy/pull/12135" +prs = ["12135"] file_name = "12135_Support_wireframes_for_2D_meshes.md" [[release_notes]] title = "Custom Reflect Field Attributes" authors = ["@MrGVSV"] -url = "https://github.com/bevyengine/bevy/pull/11659" +prs = ["11659"] file_name = "11659_bevy_reflect_Custom_attributes.md" [[release_notes]] title = "Query Iteration Sorting" authors = ["@Victoronz"] -url = "https://github.com/bevyengine/bevy/pull/13417" +prs = ["13417"] file_name = "13417_implement_the_full_set_of_sort_methods_on_QueryIter.md" [[release_notes]] title = "SystemBuilder" authors = ["@james-j-obrien"] -url = "https://github.com/bevyengine/bevy/pull/13123" +prs = ["13123"] file_name = "13123_Implement_a_SystemBuilder_for_building_SystemParams.md" [[release_notes]] title = "Throttle Render Assets" authors = ["@robtfm", "@IceSentry", "@mockersf"] -url = "https://github.com/bevyengine/bevy/pull/12622" +prs = ["12622"] file_name = "12622_Throttle_render_assets.md" [[release_notes]] title = "StandardMaterial UV Channel Selection" authors = ["@geckoxx"] -url = "https://github.com/bevyengine/bevy/pull/13200" +prs = ["13200"] file_name = "13200_Add_UV_channel_selection_to_StandardMaterial.md" [[release_notes]] title = "Remove limit on RenderLayers" authors = ["@tychedelia", "@robtfm", "@UkoeHB"] -url = "https://github.com/bevyengine/bevy/pull/13317" +prs = ["13317"] file_name = "13317_12502_Remove_limit_on_RenderLayers.md" [[release_notes]] title = "`on_unimplemented` Diagnostics" authors = ["@bushrat011899", "@alice-i-cecile", "@Themayu"] -url = "https://github.com/bevyengine/bevy/pull/13347" +prs = ["13347"] file_name = "13347_Add_on_unimplemented_Diagnostics_to_Most_Public_Traits.md" [[release_notes]] title = "Motion Vectors and TAA for Animated Meshes" authors = ["@pcwalton"] -url = "https://github.com/bevyengine/bevy/pull/13572" +prs = ["13572"] file_name = "13572_Implement_motion_vectors_and_TAA_for_skinned_meshes_and_me.md" [[release_notes]] title = "Improved Matrix Naming" authors = ["@ricky26"] -url = "https://github.com/bevyengine/bevy/pull/13489" +prs = ["13489"] file_name = "13489_Normalise_matrix_naming.md" [[release_notes]] title = "Typed glTF Labels" authors = ["@mockersf", "@rparrett", "@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/13586" +prs = ["13586"] file_name = "13586_glTF_labels_add_enum_to_avoid_misspelling_and_keep_uptodat.md" [[release_notes]] title = "winit v0.30" authors = ["@pietrosophya", "@mockersf"] -url = "https://github.com/bevyengine/bevy/pull/13366" +prs = ["13366"] file_name = "13366_fix_upgrade_to_winit_v030.md" [[release_notes]] title = "Scene, Mesh, and Material glTF Extras" authors = ["@kaosat-dev"] -url = "https://github.com/bevyengine/bevy/pull/13453" +prs = ["13453"] file_name = "13453_add_handling_of_all_missing_gltf_extras_scene_mesh__materi.md" [[release_notes]] title = "Resource Entity Mapping in Scenes" authors = ["@brandon-reinhart"] -url = "https://github.com/bevyengine/bevy/pull/13650" +prs = ["13650"] file_name = "13650_Map_entities_from_a_resource_when_written_to_the_world.md" [[release_notes]] title = "CompassQuadrant and CompassOctant" authors = ["@BobG1983", "@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/13653" +prs = ["13653"] file_name = "13653_Added_CompassQuadrant_and_CompassOctant_as_per_13647.md" [[release_notes]] title = "Support `AsyncSeek` When Loading Assets" authors = ["@BeastLe9enD"] -url = "https://github.com/bevyengine/bevy/pull/12547" +prs = ["12547"] file_name = "12547_Add_AsyncSeek_trait_to_Reader_to_be_able_to_seek_inside_as.md" [[release_notes]] title = "LoadState::Failed Now Has Error Info" authors = ["@bugsweeper"] -url = "https://github.com/bevyengine/bevy/pull/12709" +prs = ["12709"] file_name = "12709_Error_info_has_been_added_to_LoadStateFailed.md" [[release_notes]] title = "`AppExit` Errors" authors = ["@Brezak", "@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/13022" +prs = ["13022"] file_name = "13022_Make_AppExit_more_specific_about_exit_reason.md" [[release_notes]] title = "Make dynamic_linking a no-op on WASM targets" authors = ["@james7132"] -url = "https://github.com/bevyengine/bevy/pull/12672" +prs = ["12672"] file_name = "12672_Make_dynamic_linking_a_noop_on_wasm_targets.md" [[release_notes]] title = "Deprecate Dynamic Plugins" authors = ["@BD103"] -url = "https://github.com/bevyengine/bevy/pull/13080" +prs = ["13080"] file_name = "13080_Deprecate_dynamic_plugins.md" [[release_notes]] title = "Bevy Working Groups" authors = ["@alice-i-cecile"] -url = "https://github.com/bevyengine/bevy/pull/13162" +prs = ["13162"] file_name = "13162_Add_a_process_for_working_groups.md" diff --git a/release-content/0.15/migration-guides/11741_Send_SceneInstanceReady_when_spawning_any_kind_of_scene.md b/release-content/0.15/migration-guides/11741_Send_SceneInstanceReady_when_spawning_any_kind_of_scene.md new file mode 100644 index 0000000000..185d81bfec --- /dev/null +++ b/release-content/0.15/migration-guides/11741_Send_SceneInstanceReady_when_spawning_any_kind_of_scene.md @@ -0,0 +1 @@ +- `SceneInstanceReady { parent: Entity }` is now `SceneInstanceReady { id: InstanceId, parent: Option }`. diff --git a/release-content/0.15/migration-guides/12095_Add_features_to_switch_NativeActivity_and_GameActivity_usa.md b/release-content/0.15/migration-guides/12095_Add_features_to_switch_NativeActivity_and_GameActivity_usa.md new file mode 100644 index 0000000000..0e0656c2e7 --- /dev/null +++ b/release-content/0.15/migration-guides/12095_Add_features_to_switch_NativeActivity_and_GameActivity_usa.md @@ -0,0 +1,2 @@ +Because `cargo-apk` is not compatible with `GameActivity`, building/running using `cargo apk build/run -p bevy_mobile_example` is no longer possible. +Users should follow the new workflow described in document. diff --git a/release-content/0.15/migration-guides/12770_Implement_gamepads_as_entities.md b/release-content/0.15/migration-guides/12770_Implement_gamepads_as_entities.md new file mode 100644 index 0000000000..0ff2062821 --- /dev/null +++ b/release-content/0.15/migration-guides/12770_Implement_gamepads_as_entities.md @@ -0,0 +1,44 @@ +Gamepad input is no longer accessed using resources, instead they are entities and are accessible using the Gamepad component as long as the gamepad is connected. + +Gamepads resource has been deleted, instead of using an internal id to identify gamepads you can use its Entity. Disconnected gamepads will **NOT** be despawned. Gamepad components that don’t need to preserve their state will be removed i.e. Gamepad component is removed, but GamepadSettings is kept. +Reconnected gamepads will try to preserve their Entity id and necessary components will be re-inserted. + +GamepadSettings is no longer a resource, instead it is a component attached to the Gamepad entity. + +Axis, Axis and ButtonInput methods are accessible via Gamepad component. + +```diff +fn gamepad_system( +- gamepads: Res, +- button_inputs: Res>, +- button_axes: Res>, +- axes: Res>, ++ gamepads: Query<&Gamepad> +) { + for gamepad in gamepads.iter() { +- if button_inputs.just_pressed(GamepadButton::new(gamepad, GamepadButtonType::South)) { ++ if gamepad.just_pressed(GamepadButton::South) { + println!("just pressed South"); + } + +- let right_trigger = button_axes +- .get(GamepadButton::new( +- gamepad, +- GamepadButtonType::RightTrigger2, +- )) +- .unwrap(); ++ let right_trigger = gamepad.get(GamepadButton::RightTrigger2).unwrap(); + if right_trigger.abs() > 0.01 { + info!("RightTrigger2 value is {}", right_trigger); + } + +- let left_stick_x = axes +- .get(GamepadAxis::new(gamepad, GamepadAxisType::LeftStickX)) +- .unwrap(); ++ let left_stick_x = gamepad.get(GamepadAxis::LeftStickX).unwrap(); + if left_stick_x.abs() > 0.01 { + info!("LeftStickX value is {}", left_stick_x); + } + } +} +``` diff --git a/release-content/0.15/migration-guides/12929_Remove_redundant_information_and_optimize_dynamic_allocati.md b/release-content/0.15/migration-guides/12929_Remove_redundant_information_and_optimize_dynamic_allocati.md new file mode 100644 index 0000000000..6e8d661b49 --- /dev/null +++ b/release-content/0.15/migration-guides/12929_Remove_redundant_information_and_optimize_dynamic_allocati.md @@ -0,0 +1,3 @@ +`Table` now uses `ThinColumn` instead of `Column`. That means that methods that previously returned `Column`, will now return `ThinColumn` instead. + +`ThinColumn` has a much more limited and low-level API, but you can still achieve the same things in `ThinColumn` as you did in `Column`. For example, instead of calling `Column::get_added_tick`, you’d call `ThinColumn::get_added_ticks_slice` and index it to get the specific added tick. diff --git a/release-content/0.15/migration-guides/13014_Dedicated_Reflect_implementation_for_Setlike_things.md b/release-content/0.15/migration-guides/13014_Dedicated_Reflect_implementation_for_Setlike_things.md new file mode 100644 index 0000000000..89405a6163 --- /dev/null +++ b/release-content/0.15/migration-guides/13014_Dedicated_Reflect_implementation_for_Setlike_things.md @@ -0,0 +1,5 @@ +- The new `Set` variants on the enums listed in the change section should probably be considered by people working with this level of the lib + +__Help wanted!__ + +I’m not sure if this change is able to break code. From my understanding it shouldn’t since we just add functionality but I’m not sure yet if theres anything missing from my impl that would be normally provided by `impl_reflect_value!` diff --git a/release-content/0.15/migration-guides/13069_Add_2d_opaque_phase_with_depth_buffer.md b/release-content/0.15/migration-guides/13069_Add_2d_opaque_phase_with_depth_buffer.md new file mode 100644 index 0000000000..6c4e7e438b --- /dev/null +++ b/release-content/0.15/migration-guides/13069_Add_2d_opaque_phase_with_depth_buffer.md @@ -0,0 +1 @@ +- `ColorMaterial` now contains `AlphaMode2d`. To keep previous behaviour, use `AlphaMode::BLEND`. If you know your sprite is opaque, use `AlphaMode::OPAQUE` diff --git a/release-content/0.15/migration-guides/13240_Dont_ignore_draw_errors.md b/release-content/0.15/migration-guides/13240_Dont_ignore_draw_errors.md new file mode 100644 index 0000000000..4270a53b0e --- /dev/null +++ b/release-content/0.15/migration-guides/13240_Dont_ignore_draw_errors.md @@ -0,0 +1,3 @@ +If you were using `RenderCommandResult::Failure` to just ignore an error and retry later, use `RenderCommandResult::Skip` instead. + +This wasn’t intentional, but this PR should also help with https://github.com/bevyengine/bevy/issues/12660 since we can turn a few unwraps into error messages now. diff --git a/release-content/0.15/migration-guides/13321_bevy_reflect_Nested_TypeInfo_getters.md b/release-content/0.15/migration-guides/13321_bevy_reflect_Nested_TypeInfo_getters.md new file mode 100644 index 0000000000..d738caa851 --- /dev/null +++ b/release-content/0.15/migration-guides/13321_bevy_reflect_Nested_TypeInfo_getters.md @@ -0,0 +1,5 @@ +All active fields for reflected types (including lists, maps, tuples, etc.), must implement `Typed`. For the majority of users this won’t have any visible impact. + +However, users implementing `Reflect` manually may need to update their types to implement `Typed` if they weren’t already. + +Additionally, custom dynamic types will need to implement the new hidden `MaybeTyped` trait. diff --git a/release-content/0.15/migration-guides/13454_Added_visibility_bitmask_as_an_alternative_SSAO_method.md b/release-content/0.15/migration-guides/13454_Added_visibility_bitmask_as_an_alternative_SSAO_method.md new file mode 100644 index 0000000000..59bdc4c349 --- /dev/null +++ b/release-content/0.15/migration-guides/13454_Added_visibility_bitmask_as_an_alternative_SSAO_method.md @@ -0,0 +1 @@ +SSAO algorithm was changed from GTAO to VBAO (visibility bitmasks). A new field, `constant_object_thickness`, was added to `ScreenSpaceAmbientOcclusion`. `ScreenSpaceAmbientOcclusion` also lost its `Eq` and `Hash` implementations. diff --git a/release-content/0.15/migration-guides/13620_Fix_UI_texture_atlas_with_offset.md b/release-content/0.15/migration-guides/13620_Fix_UI_texture_atlas_with_offset.md new file mode 100644 index 0000000000..17a84184b6 --- /dev/null +++ b/release-content/0.15/migration-guides/13620_Fix_UI_texture_atlas_with_offset.md @@ -0,0 +1,25 @@ +```diff +let ui_node = ExtractedUiNode { + stack_index, + transform, + color, + rect, + image, +- atlas_size: Some(atlas_size * scale_factor), ++ atlas_scaling: Some(Vec2::splat(scale_factor)), + clip, + flip_x, + flip_y, + camera_entity, + border, + border_radius, + node_type, + }, +``` + +```diff +let computed_slices = ComputedTextureSlices { + slices, +- image_size, +} +``` diff --git a/release-content/0.15/migration-guides/13669_Expose_winits_MonitorHandle.md b/release-content/0.15/migration-guides/13669_Expose_winits_MonitorHandle.md new file mode 100644 index 0000000000..f67e5c6edc --- /dev/null +++ b/release-content/0.15/migration-guides/13669_Expose_winits_MonitorHandle.md @@ -0,0 +1 @@ +- `WindowMode` variants now take a `MonitorSelection`, which can be set to `MonitorSelection::Primary` to mirror the old behavior. diff --git a/release-content/0.15/migration-guides/13712_Add_feature_requirement_info_to_image_loading_docs.md b/release-content/0.15/migration-guides/13712_Add_feature_requirement_info_to_image_loading_docs.md new file mode 100644 index 0000000000..3955c19203 --- /dev/null +++ b/release-content/0.15/migration-guides/13712_Add_feature_requirement_info_to_image_loading_docs.md @@ -0,0 +1 @@ +Image format related entities are feature gated, if there are compilation errors about unknown names there are some of features in list (`exr`, `hdr`, `basis-universal`, `png`, `dds`, `tga`, `jpeg`, `bmp`, `ktx2`, `webp` and `pnm`) should be added. diff --git a/release-content/0.15/migration-guides/13818_Created_an_EventMutator_for_when_you_want_to_mutate_an_eve.md b/release-content/0.15/migration-guides/13818_Created_an_EventMutator_for_when_you_want_to_mutate_an_eve.md new file mode 100644 index 0000000000..c8c04a488b --- /dev/null +++ b/release-content/0.15/migration-guides/13818_Created_an_EventMutator_for_when_you_want_to_mutate_an_eve.md @@ -0,0 +1,3 @@ +Users currently using `ManualEventReader` should use `EventCursor` instead. `ManualEventReader` will be removed in Bevy 0.16. Additionally, `Events::get_reader` has been replaced by `Events::get_cursor`. + +Users currently directly accessing the `Events` resource for mutation should move to `EventMutator` if possible. diff --git a/release-content/0.15/migration-guides/13855_Align_Scenewrite_to_world_with_to_match_DynamicScenewrite_.md b/release-content/0.15/migration-guides/13855_Align_Scenewrite_to_world_with_to_match_DynamicScenewrite_.md new file mode 100644 index 0000000000..d42524c8d8 --- /dev/null +++ b/release-content/0.15/migration-guides/13855_Align_Scenewrite_to_world_with_to_match_DynamicScenewrite_.md @@ -0,0 +1,14 @@ +`Scene::write_to_world_with` no longer returns an `InstanceInfo`. + +Before + +```rust +scene.write_to_world_with(world, ®istry) +``` + +After + +```rust +let mut entity_map = EntityHashMap::default(); +scene.write_to_world_with(world, &mut entity_map, ®istry) +``` diff --git a/release-content/0.15/migration-guides/13859_Change_SceneInstanceReady_to_trigger_an_observer.md b/release-content/0.15/migration-guides/13859_Change_SceneInstanceReady_to_trigger_an_observer.md new file mode 100644 index 0000000000..7fa679058c --- /dev/null +++ b/release-content/0.15/migration-guides/13859_Change_SceneInstanceReady_to_trigger_an_observer.md @@ -0,0 +1,16 @@ +If you have a system which read `SceneInstanceReady` events: + +> +`fn ready_system(ready_events: EventReader<'_, '_, SceneInstanceReady>) {` + + +It must be rewritten as an observer: + +> +`commands.observe(|trigger: Trigger| {` + + +Or, if you were expecting the event in relation to a specific entity or entities, as an entity observer: + +> +`commands.entity(entity).observe(|trigger: Trigger| {` diff --git a/release-content/0.15/migration-guides/13871_Replaced_implicit_emissive_weight_with_default.md b/release-content/0.15/migration-guides/13871_Replaced_implicit_emissive_weight_with_default.md new file mode 100644 index 0000000000..cf873b4c07 --- /dev/null +++ b/release-content/0.15/migration-guides/13871_Replaced_implicit_emissive_weight_with_default.md @@ -0,0 +1 @@ + diff --git a/release-content/0.15/migration-guides/13991_Minimal_Bubbling_Observers.md b/release-content/0.15/migration-guides/13991_Minimal_Bubbling_Observers.md new file mode 100644 index 0000000000..9ebf9af403 --- /dev/null +++ b/release-content/0.15/migration-guides/13991_Minimal_Bubbling_Observers.md @@ -0,0 +1,3 @@ +- Manual implementations of `Event` should add associated type `Traverse = TraverseNone` and associated constant `AUTO_PROPAGATE = false`; +- `Trigger::new` has new field `propagation: &mut Propagation` which provides the bubbling state. +- `ObserverRunner` now takes the same `&mut Propagation` as a final parameter. diff --git a/release-content/0.15/migration-guides/14034_Track_source_location_in_change_detection.md b/release-content/0.15/migration-guides/14034_Track_source_location_in_change_detection.md new file mode 100644 index 0000000000..90c154d7c1 --- /dev/null +++ b/release-content/0.15/migration-guides/14034_Track_source_location_in_change_detection.md @@ -0,0 +1 @@ +- Added `changed_by` field to many internal ECS functions used with change detection when the `track_change_detection` feature flag is enabled. Use Location::caller() to provide the source of the function call. diff --git a/release-content/0.15/migration-guides/14050_Support_more_kinds_of_system_params_in_buildable_systems.md b/release-content/0.15/migration-guides/14050_Support_more_kinds_of_system_params_in_buildable_systems.md new file mode 100644 index 0000000000..d0cae12181 --- /dev/null +++ b/release-content/0.15/migration-guides/14050_Support_more_kinds_of_system_params_in_buildable_systems.md @@ -0,0 +1,19 @@ +The API for `SystemBuilder` has changed. Instead of constructing a builder with a world and then adding params, you first create a tuple of param builders and then supply the world. + +```rust +// Before +let system = SystemBuilder::<()>::new(&mut world) + .local::() + .builder::>(|x| *x = 10) + .builder::>(|builder| { builder.with::(); }) + .build(system); + +// After +let system = ( + ParamBuilder, + LocalBuilder(10), + QueryParamBuilder::new(|builder| { builder.with::(); }), +) + .build_state(&mut world) + .build_system(system); +``` diff --git a/release-content/0.15/migration-guides/14073_Lighting_Should_Only_hold_VecEntity_instead_of_TypeIdVecEn.md b/release-content/0.15/migration-guides/14073_Lighting_Should_Only_hold_VecEntity_instead_of_TypeIdVecEn.md new file mode 100644 index 0000000000..2533fbe0d5 --- /dev/null +++ b/release-content/0.15/migration-guides/14073_Lighting_Should_Only_hold_VecEntity_instead_of_TypeIdVecEn.md @@ -0,0 +1,2 @@ +> +now `SpotLightBundle` , `CascadesVisibleEntities `and `CubemapVisibleEntities `use VisibleMeshEntities instead of `VisibleEntities` diff --git a/release-content/0.15/migration-guides/14099_Allow_volumetric_fog_to_be_localized_to_specific_optionally.md b/release-content/0.15/migration-guides/14099_Allow_volumetric_fog_to_be_localized_to_specific_optionally.md new file mode 100644 index 0000000000..9651b9d2e9 --- /dev/null +++ b/release-content/0.15/migration-guides/14099_Allow_volumetric_fog_to_be_localized_to_specific_optionally.md @@ -0,0 +1 @@ +- A `FogVolume` is now necessary in order to enable volumetric fog, in addition to `VolumetricFogSettings` on the camera. Existing uses of volumetric fog can be migrated by placing a large `FogVolume` surrounding the scene. diff --git a/release-content/0.15/migration-guides/14178_Remove_unused_type_parameter_in_Paralleldrain.md b/release-content/0.15/migration-guides/14178_Remove_unused_type_parameter_in_Paralleldrain.md new file mode 100644 index 0000000000..9d5d154ef7 --- /dev/null +++ b/release-content/0.15/migration-guides/14178_Remove_unused_type_parameter_in_Paralleldrain.md @@ -0,0 +1,21 @@ +The type parameter of `Parallel::drain()` was unused, so it is now removed. If you were manually specifying it, you can remove the bounds. + +```rust +// 0.14 +// Create a `Parallel` and give it a value. +let mut parallel: Parallel> = Parallel::default(); +*parallel.borrow_local_mut() = vec![1, 2, 3]; + +for v in parallel.drain::() { + // ... +} + +// 0.15 +let mut parallel: Parallel> = Parallel::default(); +*parallel.borrow_local_mut() = vec![1, 2, 3]; + +// Remove the type parameter. +for v in parallel.drain() { + // ... +} +``` diff --git a/release-content/0.15/migration-guides/14193_Faster_MeshletMesh_deserialization.md b/release-content/0.15/migration-guides/14193_Faster_MeshletMesh_deserialization.md new file mode 100644 index 0000000000..bc25073886 --- /dev/null +++ b/release-content/0.15/migration-guides/14193_Faster_MeshletMesh_deserialization.md @@ -0,0 +1,6 @@ +- Regenerate your `MeshletMesh` assets, as the disk format has changed, and `MESHLET_MESH_ASSET_VERSION` has been bumped +- `MeshletMesh` fields are now private +- `MeshletMeshSaverLoad` is now named `MeshletMeshSaverLoader` +- The `Meshlet`, `MeshletBoundingSpheres`, and `MeshletBoundingSphere` types are now private +- `MeshletMeshSaveOrLoadError::SerializationOrDeserialization` has been removed +- Added `MeshletMeshSaveOrLoadError::WrongFileType`, match on this variant if you match on `MeshletMeshSaveOrLoadError` diff --git a/release-content/0.15/migration-guides/14194_Replace_AsyncSeek_trait_by_AsyncSeekForward_for_Reader_to_.md b/release-content/0.15/migration-guides/14194_Replace_AsyncSeek_trait_by_AsyncSeekForward_for_Reader_to_.md new file mode 100644 index 0000000000..82f5bb13ac --- /dev/null +++ b/release-content/0.15/migration-guides/14194_Replace_AsyncSeek_trait_by_AsyncSeekForward_for_Reader_to_.md @@ -0,0 +1 @@ +Replace all instances of `AsyncSeek` with `AsyncSeekForward` in your asset reader implementations. diff --git a/release-content/0.15/migration-guides/14198_Remove_need_for_EventLoopProxy_to_be_NonSend.md b/release-content/0.15/migration-guides/14198_Remove_need_for_EventLoopProxy_to_be_NonSend.md new file mode 100644 index 0000000000..59c4553c3c --- /dev/null +++ b/release-content/0.15/migration-guides/14198_Remove_need_for_EventLoopProxy_to_be_NonSend.md @@ -0,0 +1,17 @@ +`EventLoopProxy` has been renamed to `EventLoopProxyWrapper` and is now `Send`, making it an ordinary resource. + +Before: + +```rust +event_loop_system(event_loop: NonSend>) { + event_loop.send_event(MyEvent); +} +``` + +After: + +```rust +event_loop_system(event_loop: Res>) { + event_loop.send_event(MyEvent); +} +``` diff --git a/release-content/0.15/migration-guides/14211_Rename_bevy_corenameDebugName_to_bevy_corenameNameOrEntity.md b/release-content/0.15/migration-guides/14211_Rename_bevy_corenameDebugName_to_bevy_corenameNameOrEntity.md new file mode 100644 index 0000000000..01375c1b02 --- /dev/null +++ b/release-content/0.15/migration-guides/14211_Rename_bevy_corenameDebugName_to_bevy_corenameNameOrEntity.md @@ -0,0 +1 @@ +- Rename usages of `bevy_core::name::DebugName` to `bevy_core::name::NameOrEntity` diff --git a/release-content/0.15/migration-guides/14228_Clean_up_UiSystem_system_sets.md b/release-content/0.15/migration-guides/14228_Clean_up_UiSystem_system_sets.md new file mode 100644 index 0000000000..f80d59efeb --- /dev/null +++ b/release-content/0.15/migration-guides/14228_Clean_up_UiSystem_system_sets.md @@ -0,0 +1,3 @@ +`UiSystem` system set adjustments. + +- The `UiSystem::Outline` system set is now strictly ordered after `UiSystem::Layout`, rather than overlapping it. diff --git a/release-content/0.15/migration-guides/14250_Implement_FromIteratorIntoIterator_for_dynamic_types.md b/release-content/0.15/migration-guides/14250_Implement_FromIteratorIntoIterator_for_dynamic_types.md new file mode 100644 index 0000000000..2da19481c7 --- /dev/null +++ b/release-content/0.15/migration-guides/14250_Implement_FromIteratorIntoIterator_for_dynamic_types.md @@ -0,0 +1 @@ +- Change `DynamicArray::from_vec` to `DynamicArray::from_iter` diff --git a/release-content/0.15/migration-guides/14257_Pack_multiple_vertex_and_index_arrays_together_into_growab.md b/release-content/0.15/migration-guides/14257_Pack_multiple_vertex_and_index_arrays_together_into_growab.md new file mode 100644 index 0000000000..2af5a0be49 --- /dev/null +++ b/release-content/0.15/migration-guides/14257_Pack_multiple_vertex_and_index_arrays_together_into_growab.md @@ -0,0 +1,5 @@ +__Changed__ + +- Vertex and index buffers for meshes may now be packed alongside other buffers, for performance. +- `GpuMesh` has been renamed to `RenderMesh`, to reflect the fact that it no longer directly stores handles to GPU objects. +- Because meshes no longer have their own vertex and index buffers, the responsibility for the buffers has moved from `GpuMesh` (now called `RenderMesh`) to the `MeshAllocator` resource. To access the vertex data for a mesh, use `MeshAllocator::mesh_vertex_slice`. To access the index data for a mesh, use `MeshAllocator::mesh_index_slice`. diff --git a/release-content/0.15/migration-guides/14267_Add_support_for_skybox_transformation.md b/release-content/0.15/migration-guides/14267_Add_support_for_skybox_transformation.md new file mode 100644 index 0000000000..5e9f31e6ed --- /dev/null +++ b/release-content/0.15/migration-guides/14267_Add_support_for_skybox_transformation.md @@ -0,0 +1 @@ +- Since we have added a new filed to the Skybox struct, users will need to include `..Default::default()` or some rotation value in their initialization code. diff --git a/release-content/0.15/migration-guides/14273_Move_Msaa_to_component.md b/release-content/0.15/migration-guides/14273_Move_Msaa_to_component.md new file mode 100644 index 0000000000..a1ec2c53e4 --- /dev/null +++ b/release-content/0.15/migration-guides/14273_Move_Msaa_to_component.md @@ -0,0 +1 @@ +`Msaa` is no longer configured as a global resource, and should be specified on each spawned camera if a non-default setting is desired. diff --git a/release-content/0.15/migration-guides/14284_Add_custom_cursors.md b/release-content/0.15/migration-guides/14284_Add_custom_cursors.md new file mode 100644 index 0000000000..f2e54589bb --- /dev/null +++ b/release-content/0.15/migration-guides/14284_Add_custom_cursors.md @@ -0,0 +1,3 @@ +- `CursorIcon` is no longer a field in `Window`, but a separate component can be inserted to a window entity. It has been changed to an enum that can hold custom images in addition to system icons. +- `Cursor` is renamed to `CursorOptions` and `cursor` field of `Window` is renamed to `cursor_options` +- `CursorIcon` is renamed to `SystemCursorIcon` diff --git a/release-content/0.15/migration-guides/14285_Remove_second_generic_from_add_before_add_after.md b/release-content/0.15/migration-guides/14285_Remove_second_generic_from_add_before_add_after.md new file mode 100644 index 0000000000..ecf6692da0 --- /dev/null +++ b/release-content/0.15/migration-guides/14285_Remove_second_generic_from_add_before_add_after.md @@ -0,0 +1,15 @@ +Removed second generic from `PluginGroupBuilder` methods: `add_before` and `add_after`. + +```rust +// Before: +DefaultPlugins + .build() + .add_before::(FooPlugin) + .add_after::(BarPlugin) + +// After: +DefaultPlugins + .build() + .add_before::(FooPlugin) + .add_after::(BarPlugin) +``` diff --git a/release-content/0.15/migration-guides/14290_Add_support_for_environment_map_transformation.md b/release-content/0.15/migration-guides/14290_Add_support_for_environment_map_transformation.md new file mode 100644 index 0000000000..5740331d23 --- /dev/null +++ b/release-content/0.15/migration-guides/14290_Add_support_for_environment_map_transformation.md @@ -0,0 +1 @@ +- Since we have added a new filed to the `EnvironmentMapLight` struct, users will need to include `..default()` or some rotation value in their initialization code. diff --git a/release-content/0.15/migration-guides/14313_Remove_unused_default_feature_from_bevy_window.md b/release-content/0.15/migration-guides/14313_Remove_unused_default_feature_from_bevy_window.md new file mode 100644 index 0000000000..3dc69affdf --- /dev/null +++ b/release-content/0.15/migration-guides/14313_Remove_unused_default_feature_from_bevy_window.md @@ -0,0 +1,11 @@ +`bevy_window` had an empty default feature flag that did not do anything, so it was removed. You may have to remove any references to it if you specified it manually. + +```toml +# 0.14 +[dependencies] +bevy_window = { version = "0.14", default-features = false, features = ["default"] } + +# 0.15 +[dependencies] +bevy_window = { version = "0.15", default-features = false } +``` diff --git a/release-content/0.15/migration-guides/14325_Added_new_method_to_Cone_3D_primitive.md b/release-content/0.15/migration-guides/14325_Added_new_method_to_Cone_3D_primitive.md new file mode 100644 index 0000000000..e4356916c4 --- /dev/null +++ b/release-content/0.15/migration-guides/14325_Added_new_method_to_Cone_3D_primitive.md @@ -0,0 +1 @@ +- Addition of `new` method to the 3D primitive Cone struct. diff --git a/release-content/0.15/migration-guides/14343_Export_glTF_skins_as_a_Gltf_struct.md b/release-content/0.15/migration-guides/14343_Export_glTF_skins_as_a_Gltf_struct.md new file mode 100644 index 0000000000..a465e849f9 --- /dev/null +++ b/release-content/0.15/migration-guides/14343_Export_glTF_skins_as_a_Gltf_struct.md @@ -0,0 +1 @@ +- Change `GltfAssetLabel::Skin(..)` to `GltfAssetLabel::InverseBindMatrices(..)`. diff --git a/release-content/0.15/migration-guides/14352_Add_FilteredAccessempty_and_simplify_the_implementation_of_.md b/release-content/0.15/migration-guides/14352_Add_FilteredAccessempty_and_simplify_the_implementation_of_.md new file mode 100644 index 0000000000..ed0c9aafee --- /dev/null +++ b/release-content/0.15/migration-guides/14352_Add_FilteredAccessempty_and_simplify_the_implementation_of_.md @@ -0,0 +1 @@ +- The behaviour of `AnyOf<()>` and `Or<()>` has been changed to match no archetypes rather than all archetypes to naturally match the corresponding logical operation. Consider replacing them with `()` instead. diff --git a/release-content/0.15/migration-guides/14354_Update_trigger_observers_to_operate_over_slices_of_data.md b/release-content/0.15/migration-guides/14354_Update_trigger_observers_to_operate_over_slices_of_data.md new file mode 100644 index 0000000000..97bdc3e059 --- /dev/null +++ b/release-content/0.15/migration-guides/14354_Update_trigger_observers_to_operate_over_slices_of_data.md @@ -0,0 +1 @@ +- TBD diff --git a/release-content/0.15/migration-guides/14357_Using_Cas_instead_of_CAS_14341.md b/release-content/0.15/migration-guides/14357_Using_Cas_instead_of_CAS_14341.md new file mode 100644 index 0000000000..cf873b4c07 --- /dev/null +++ b/release-content/0.15/migration-guides/14357_Using_Cas_instead_of_CAS_14341.md @@ -0,0 +1 @@ + diff --git a/release-content/0.15/migration-guides/14373_Optimize_transform_propagation.md b/release-content/0.15/migration-guides/14373_Optimize_transform_propagation.md new file mode 100644 index 0000000000..3bb9592532 --- /dev/null +++ b/release-content/0.15/migration-guides/14373_Optimize_transform_propagation.md @@ -0,0 +1 @@ +This change does not introduce any breaking changes. Users of the Bevy engine will automatically benefit from this performance improvement without needing to modify their code. diff --git a/release-content/0.15/migration-guides/14382_Disallow_empty_cubic_and_rational_curves.md b/release-content/0.15/migration-guides/14382_Disallow_empty_cubic_and_rational_curves.md new file mode 100644 index 0000000000..0845410aed --- /dev/null +++ b/release-content/0.15/migration-guides/14382_Disallow_empty_cubic_and_rational_curves.md @@ -0,0 +1,5 @@ +The `to_curve` method on Bevy’s cubic splines is now fallible (returning a `Result`), meaning that any existing calls will need to be updated by handling the possibility of an error variant. + +Similarly, any custom implementation of `CubicGenerator` or `RationalGenerator` will need to be amended to include an `Error` type and be made fallible itself. + +Finally, the fields of `CubicCurve` and `RationalCurve` are now private, so any direct constructions of these structs from segments will need to be replaced with the new `CubicCurve::from_segments` and `RationalCurve::from_segments` methods. diff --git a/release-content/0.15/migration-guides/14384_Only_propagate_transforms_entities_with_GlobalTransforms.md b/release-content/0.15/migration-guides/14384_Only_propagate_transforms_entities_with_GlobalTransforms.md new file mode 100644 index 0000000000..9d3356f9b4 --- /dev/null +++ b/release-content/0.15/migration-guides/14384_Only_propagate_transforms_entities_with_GlobalTransforms.md @@ -0,0 +1 @@ +- To avoid surprising performance pitfalls, `Transform` / `GlobalTransform` propagation is no longer performed down through hierarchies where intermediate parent are missing a `GlobalTransform`. To restore the previous behavior, add `GlobalTransform::default` to intermediate entities. diff --git a/release-content/0.15/migration-guides/14394_Changed_Meshattributes_functions_to_return_MeshVertexAttri.md b/release-content/0.15/migration-guides/14394_Changed_Meshattributes_functions_to_return_MeshVertexAttri.md new file mode 100644 index 0000000000..d5500f300d --- /dev/null +++ b/release-content/0.15/migration-guides/14394_Changed_Meshattributes_functions_to_return_MeshVertexAttri.md @@ -0,0 +1 @@ +- When using the iterator returned by `Mesh::attributes` or `Mesh::attributes_mut` the first value of the tuple is not the `MeshVertexAttribute` instead of `MeshVertexAttributeId`. To access the `MeshVertexAttributeId` use the `MeshVertexAttribute.id` field. diff --git a/release-content/0.15/migration-guides/14416_feat_Add_Worldget_reflect_and_Worldget_reflect_mut.md b/release-content/0.15/migration-guides/14416_feat_Add_Worldget_reflect_and_Worldget_reflect_mut.md new file mode 100644 index 0000000000..6e9af6949c --- /dev/null +++ b/release-content/0.15/migration-guides/14416_feat_Add_Worldget_reflect_and_Worldget_reflect_mut.md @@ -0,0 +1 @@ +No breaking changes, but users can use the new methods if they did it manually before. diff --git a/release-content/0.15/migration-guides/14430_Fix_error_in_bevy_ui_when_building_without_bevy_text.md b/release-content/0.15/migration-guides/14430_Fix_error_in_bevy_ui_when_building_without_bevy_text.md new file mode 100644 index 0000000000..858751b790 --- /dev/null +++ b/release-content/0.15/migration-guides/14430_Fix_error_in_bevy_ui_when_building_without_bevy_text.md @@ -0,0 +1,3 @@ +**This is not a breaking change for users migrating from 0.14, since `MeasureArgs` did not exist then.** + +When the `bevy_text` feature is disabled for `bevy_ui`, the type of the `MeasureArgs::font_system` field is now a `PhantomData` instead of being removed entirely. This is in order to keep the lifetime parameter, even though it is unused without text being enabled. diff --git a/release-content/0.15/migration-guides/14441_Simplify_run_conditions.md b/release-content/0.15/migration-guides/14441_Simplify_run_conditions.md new file mode 100644 index 0000000000..b1a39ba381 --- /dev/null +++ b/release-content/0.15/migration-guides/14441_Simplify_run_conditions.md @@ -0,0 +1,21 @@ +Some run conditions have been simplified. + +```rust +// Before: +app.add_systems(Update, ( + system_0.run_if(run_once()), + system_1.run_if(resource_changed_or_removed::()), + system_2.run_if(resource_removed::()), + system_3.run_if(on_event::()), + system_4.run_if(any_component_removed::()), +)); + +// After: +app.add_systems(Update, ( + system_0.run_if(run_once), + system_1.run_if(resource_changed_or_removed::), + system_2.run_if(resource_removed::), + system_3.run_if(on_event::), + system_4.run_if(any_component_removed::), +)); +``` diff --git a/release-content/0.15/migration-guides/14448_Making_bevy_render_an_optional_dependency_for_bevy_gizmos.md b/release-content/0.15/migration-guides/14448_Making_bevy_render_an_optional_dependency_for_bevy_gizmos.md new file mode 100644 index 0000000000..ba73e618a5 --- /dev/null +++ b/release-content/0.15/migration-guides/14448_Making_bevy_render_an_optional_dependency_for_bevy_gizmos.md @@ -0,0 +1 @@ +No user-visible changes needed from the users. diff --git a/release-content/0.15/migration-guides/14459_Require_mut_self_for_Worldincrement_change_tick.md b/release-content/0.15/migration-guides/14459_Require_mut_self_for_Worldincrement_change_tick.md new file mode 100644 index 0000000000..f29370daa2 --- /dev/null +++ b/release-content/0.15/migration-guides/14459_Require_mut_self_for_Worldincrement_change_tick.md @@ -0,0 +1,11 @@ +The method `World::increment_change_tick` now requires `&mut self` instead of `&self`. If you need to call this method but do not have mutable access to the world, consider using `world.as_unsafe_world_cell_readonly().increment_change_tick()`, which does the same thing, but is less efficient than the method on `World` due to requiring atomic synchronization. + +```rust +fn my_system(world: &World) { + // Before + world.increment_change_tick(); + + // After + world.as_unsafe_world_cell_readonly().increment_change_tick(); +} +``` diff --git a/release-content/0.15/migration-guides/14485_Refactor_Bounded2dBounded3d_to_use_isometries.md b/release-content/0.15/migration-guides/14485_Refactor_Bounded2dBounded3d_to_use_isometries.md new file mode 100644 index 0000000000..b8fc038316 --- /dev/null +++ b/release-content/0.15/migration-guides/14485_Refactor_Bounded2dBounded3d_to_use_isometries.md @@ -0,0 +1,21 @@ +The `Bounded2d` and `Bounded3d` traits now take `Isometry2d` and `Isometry3d` parameters (respectively) instead of separate translation and rotation arguments. Existing calls to `aabb_2d`, `bounding_circle`, `aabb_3d`, and `bounding_sphere` will have to be changed to use isometries instead. A straightforward conversion is to refactor just by calling `Isometry2d/3d::new`, as follows: + +```rust +// Old: +let aabb = my_shape.aabb_2d(my_translation, my_rotation); + +// New: +let aabb = my_shape.aabb_2d(Isometry2d::new(my_translation, my_rotation)); +``` + +However, if the old translation and rotation are 3d translation/rotations originating from a `Transform` or `GlobalTransform`, then `to_isometry` may be used instead. For example: + +```rust +// Old: +let bounding_sphere = my_shape.bounding_sphere(shape_transform.translation, shape_transform.rotation); + +// New: +let bounding_sphere = my_shape.bounding_sphere(shape_transform.to_isometry()); +``` + +This discussion also applies to the `from_point_cloud` construction method of `Aabb2d`/`BoundingCircle`/`Aabb3d`/`BoundingSphere`, which has similarly been altered to use isometries. diff --git a/release-content/0.15/migration-guides/14534_Remove_deprecated_bevy_dynamic_plugin.md b/release-content/0.15/migration-guides/14534_Remove_deprecated_bevy_dynamic_plugin.md new file mode 100644 index 0000000000..e8e123f735 --- /dev/null +++ b/release-content/0.15/migration-guides/14534_Remove_deprecated_bevy_dynamic_plugin.md @@ -0,0 +1 @@ +Dynamic plugins were deprecated in 0.14 for being unsound, and they have now been fully removed. Please consider using the alternatives listed in the `bevy_dynamic_plugin` crate documentation, or worst-case scenario you may copy the code from 0.14. diff --git a/release-content/0.15/migration-guides/14546_Make_AnimationPlayerstart_and_play_work_accordingly_to_doc.md b/release-content/0.15/migration-guides/14546_Make_AnimationPlayerstart_and_play_work_accordingly_to_doc.md new file mode 100644 index 0000000000..accaa172c0 --- /dev/null +++ b/release-content/0.15/migration-guides/14546_Make_AnimationPlayerstart_and_play_work_accordingly_to_doc.md @@ -0,0 +1,2 @@ +`AnimationPlayer::start` now correspondingly to its docs restarts a running animation. +`AnimationPlayer::play` doesn’t reset the weight anymore. diff --git a/release-content/0.15/migration-guides/14579_Fix_soudness_issue_with_Conflicts_involving_read_all_and_w.md b/release-content/0.15/migration-guides/14579_Fix_soudness_issue_with_Conflicts_involving_read_all_and_w.md new file mode 100644 index 0000000000..9595b94ad2 --- /dev/null +++ b/release-content/0.15/migration-guides/14579_Fix_soudness_issue_with_Conflicts_involving_read_all_and_w.md @@ -0,0 +1 @@ +The `get_conflicts` method of `Access` now returns an `AccessConflict` enum instead of simply a `Vec` of `ComponentId`s that are causing the access conflict. This can be useful in cases where there are no particular `ComponentId`s conflicting, but instead **all** of them are; for example `fn system(q1: Query, q2: Query)` diff --git a/release-content/0.15/migration-guides/14609_Explicitly_order_CameraUpdateSystem_before_UiSystemPrepare.md b/release-content/0.15/migration-guides/14609_Explicitly_order_CameraUpdateSystem_before_UiSystemPrepare.md new file mode 100644 index 0000000000..022df52a26 --- /dev/null +++ b/release-content/0.15/migration-guides/14609_Explicitly_order_CameraUpdateSystem_before_UiSystemPrepare.md @@ -0,0 +1 @@ +`CameraUpdateSystem` is now explicitly ordered before `UiSystem::Prepare` instead of being ambiguous with it. diff --git a/release-content/0.15/migration-guides/14623_Meshlet_software_raster__start_of_cleanup.md b/release-content/0.15/migration-guides/14623_Meshlet_software_raster__start_of_cleanup.md new file mode 100644 index 0000000000..3afcb58f31 --- /dev/null +++ b/release-content/0.15/migration-guides/14623_Meshlet_software_raster__start_of_cleanup.md @@ -0,0 +1 @@ +- TBD (ask me at the end of the release for meshlet changes as a whole) diff --git a/release-content/0.15/migration-guides/14631_Make_QueryStatetransmuteco_validate_the_world_of_the_Compo.md b/release-content/0.15/migration-guides/14631_Make_QueryStatetransmuteco_validate_the_world_of_the_Compo.md new file mode 100644 index 0000000000..46ddaac458 --- /dev/null +++ b/release-content/0.15/migration-guides/14631_Make_QueryStatetransmuteco_validate_the_world_of_the_Compo.md @@ -0,0 +1 @@ +- `QueryState::transmute`, `QueryState::transmute_filtered`, `QueryState::join` and `QueryState::join_filtered` now take a `impl Into` instead of a `&Components` diff --git a/release-content/0.15/migration-guides/14650_Improve_the_gizmo_for_Plane3d_reusing_grid.md b/release-content/0.15/migration-guides/14650_Improve_the_gizmo_for_Plane3d_reusing_grid.md new file mode 100644 index 0000000000..978cc73ceb --- /dev/null +++ b/release-content/0.15/migration-guides/14650_Improve_the_gizmo_for_Plane3d_reusing_grid.md @@ -0,0 +1,18 @@ +The optional builder methods on + +```rust + +gizmos.primitive_3d(&Plane3d { }, ...); + +``` + +changed from + +- `segment_length` +- `segment_count` +- `axis_count` + +to + +- `cell_count` +- `spacing` diff --git a/release-content/0.15/migration-guides/14656_Switch_rotation__translation_in_grid_gizmos.md b/release-content/0.15/migration-guides/14656_Switch_rotation__translation_in_grid_gizmos.md new file mode 100644 index 0000000000..1e46fce8f2 --- /dev/null +++ b/release-content/0.15/migration-guides/14656_Switch_rotation__translation_in_grid_gizmos.md @@ -0,0 +1 @@ +- Users might have to double check their already existing calls to all the `grid` methods. It should be more intuitive now though. diff --git a/release-content/0.15/migration-guides/14663_Adds_ShaderStorageBuffer_asset.md b/release-content/0.15/migration-guides/14663_Adds_ShaderStorageBuffer_asset.md new file mode 100644 index 0000000000..2d15f8c4f3 --- /dev/null +++ b/release-content/0.15/migration-guides/14663_Adds_ShaderStorageBuffer_asset.md @@ -0,0 +1 @@ +The `AsBindGroup` `storage` attribute has been modified to reference the new `Handle` asset instead. Usages of Vec` should be converted into assets instead. diff --git a/release-content/0.15/migration-guides/14676_Use_Isometry_in_bevy_gizmos_wherever_we_can.md b/release-content/0.15/migration-guides/14676_Use_Isometry_in_bevy_gizmos_wherever_we_can.md new file mode 100644 index 0000000000..3659233da9 --- /dev/null +++ b/release-content/0.15/migration-guides/14676_Use_Isometry_in_bevy_gizmos_wherever_we_can.md @@ -0,0 +1,9 @@ +The gizmos methods function signature changes as follows: + +- 2D + - if it took `position` & `rotation_angle` before -> `Isometry2d::new(position, Rot2::radians(rotation_angle))` + - if it just took `position` before -> `Isometry2d::from_translation(position)` + +- 3D + - if it took `position` & `rotation` before -> `Isometry3d::new(position, rotation)` + - if it just took `position` before -> `Isometry3d::from_translation(position)` diff --git a/release-content/0.15/migration-guides/14690_Add_query_reborrowing.md b/release-content/0.15/migration-guides/14690_Add_query_reborrowing.md new file mode 100644 index 0000000000..65eb7684d6 --- /dev/null +++ b/release-content/0.15/migration-guides/14690_Add_query_reborrowing.md @@ -0,0 +1 @@ +- `WorldQuery` now has an additional `shrink_fetch` method you have to implement if you were implementing `WorldQuery` manually. diff --git a/release-content/0.15/migration-guides/14720_Consistency_between_Wireframe2d_and_Wireframe.md b/release-content/0.15/migration-guides/14720_Consistency_between_Wireframe2d_and_Wireframe.md new file mode 100644 index 0000000000..d5cd18d8c5 --- /dev/null +++ b/release-content/0.15/migration-guides/14720_Consistency_between_Wireframe2d_and_Wireframe.md @@ -0,0 +1,2 @@ +- `Wireframe2dConfig`.`default_color` type is now `Color` instead of `Srgba`. Use `.into()` to convert between them. +- `Wireframe2dColor`.`color` type is now `Color` instead of `Srgba`. Use `.into()` to convert between them. diff --git a/release-content/0.15/migration-guides/14731_Fix_arc_2d_Gizmos.md b/release-content/0.15/migration-guides/14731_Fix_arc_2d_Gizmos.md new file mode 100644 index 0000000000..38136bb245 --- /dev/null +++ b/release-content/0.15/migration-guides/14731_Fix_arc_2d_Gizmos.md @@ -0,0 +1,27 @@ +- users have to adjust their usages of `arc_2d`: + - before: + +```rust +arc_2d( + pos, + angle, + arc_angle, + radius, + color +) +``` + + - after: + +```rust +arc_2d( + // this `+ arc_angle * 0.5` quirk is only if you want to preserve the previous behavior + // with the new API. + // feel free to try to fix this though since your current calls to this function most likely + // involve some computations to counter-act that quirk in the first place + Isometry2d::new(pos, Rot2::radians(angle + arc_angle * 0.5), + arc_angle, + radius, + color +) +``` diff --git a/release-content/0.15/migration-guides/14764_Add_RenderSetFinalCleanup_for_Worldclear_entities.md b/release-content/0.15/migration-guides/14764_Add_RenderSetFinalCleanup_for_Worldclear_entities.md new file mode 100644 index 0000000000..89295d80bb --- /dev/null +++ b/release-content/0.15/migration-guides/14764_Add_RenderSetFinalCleanup_for_Worldclear_entities.md @@ -0,0 +1 @@ +`World::clear_entities` is now part of `RenderSet::PostCleanup` rather than `RenderSet::Cleanup`. Your cleanup systems should likely stay in `RenderSet::Cleanup`. diff --git a/release-content/0.15/migration-guides/14790_Make_QueryFilter_an_unsafe_trait.md b/release-content/0.15/migration-guides/14790_Make_QueryFilter_an_unsafe_trait.md new file mode 100644 index 0000000000..781c4ee399 --- /dev/null +++ b/release-content/0.15/migration-guides/14790_Make_QueryFilter_an_unsafe_trait.md @@ -0,0 +1 @@ +`QueryFilter` is now an `unsafe trait`. If you were manually implementing it, you will need to verify that the `WorldQuery` implementation is read-only and then add the `unsafe` keyword to the `impl`. diff --git a/release-content/0.15/migration-guides/14793_Remove_useless_Direction_field.md b/release-content/0.15/migration-guides/14793_Remove_useless_Direction_field.md new file mode 100644 index 0000000000..b622360fe8 --- /dev/null +++ b/release-content/0.15/migration-guides/14793_Remove_useless_Direction_field.md @@ -0,0 +1 @@ +`Style` no longer has a `direction` field, and `Direction` has been deleted. They didn’t do anything, so you can delete any references to them as well. diff --git a/release-content/0.15/migration-guides/14833_Rewrite_screenshots.md b/release-content/0.15/migration-guides/14833_Rewrite_screenshots.md new file mode 100644 index 0000000000..8053ae14bb --- /dev/null +++ b/release-content/0.15/migration-guides/14833_Rewrite_screenshots.md @@ -0,0 +1 @@ +`ScreenshotManager` has been removed. To take a screenshot, spawn a `Screenshot` entity with the specified render target and provide an observer targeting the `ScreenshotCaptured` event. See the `window/screenshot` example to see an example. diff --git a/release-content/0.15/migration-guides/14838_bevy_reflect_Add_Type_type.md b/release-content/0.15/migration-guides/14838_bevy_reflect_Add_Type_type.md new file mode 100644 index 0000000000..f3a6356da4 --- /dev/null +++ b/release-content/0.15/migration-guides/14838_bevy_reflect_Add_Type_type.md @@ -0,0 +1,37 @@ +Certain type info structs now only return their item types as `Type` instead of exposing direct methods on them. + +The following methods have been removed: + +- `ArrayInfo::item_type_path_table` +- `ArrayInfo::item_type_id` +- `ArrayInfo::item_is` +- `ListInfo::item_type_path_table` +- `ListInfo::item_type_id` +- `ListInfo::item_is` +- `SetInfo::value_type_path_table` +- `SetInfo::value_type_id` +- `SetInfo::value_is` +- `MapInfo::key_type_path_table` +- `MapInfo::key_type_id` +- `MapInfo::key_is` +- `MapInfo::value_type_path_table` +- `MapInfo::value_type_id` +- `MapInfo::value_is` + +Instead, access the `Type` directly using one of the new methods: + +- `ArrayInfo::item_ty` +- `ListInfo::item_ty` +- `SetInfo::value_ty` +- `MapInfo::key_ty` +- `MapInfo::value_ty` + +For example: + +```rust +// BEFORE +let type_id = array_info.item_type_id(); + +// AFTER +let type_id = array_info.item_ty().id(); +``` diff --git a/release-content/0.15/migration-guides/14842_Replace_the_wgpu_trace_feature_with_a_field_in_bevy_render.md b/release-content/0.15/migration-guides/14842_Replace_the_wgpu_trace_feature_with_a_field_in_bevy_render.md new file mode 100644 index 0000000000..59a486b7db --- /dev/null +++ b/release-content/0.15/migration-guides/14842_Replace_the_wgpu_trace_feature_with_a_field_in_bevy_render.md @@ -0,0 +1,6 @@ +- The `bevy/wgpu_trace`, `bevy_render/wgpu_trace`, and `bevy_internal/wgpu_trace` features no longer exist. Remove them from your `Cargo.toml`, CI, tooling, and what-not. +- Follow the instructions in the updated `docs/debugging.md` file in the repository, under the WGPU Tracing section. + +Because of the changes made, you can now generate traces to any path, rather than the hardcoded `%WorkspaceRoot%/wgpu_trace` (where `%WorkspaceRoot%` is… the root of your crate’s workspace) folder. + +(If WGPU hasn’t restored tracing functionality…) Do note that WGPU has not yet restored tracing functionality. However, once it does, the above should be sufficient to generate new traces. diff --git a/release-content/0.15/migration-guides/14862_Picking_event_ordering.md b/release-content/0.15/migration-guides/14862_Picking_event_ordering.md new file mode 100644 index 0000000000..7ee85cbe44 --- /dev/null +++ b/release-content/0.15/migration-guides/14862_Picking_event_ordering.md @@ -0,0 +1,12 @@ +For users switching from `bevy_mod_picking` to `bevy_picking`: + +- Instead of adding an `On` component, use `.observe(|trigger: Trigger|)`. You may now apply multiple handlers to the same entity using this command. +- Pointer interaction events now have semi-deterministic ordering which (more or less) aligns with the order of the raw input stream. Consult the docs on `bevy_picking::event::pointer_events` for current information. You may need to adjust your event handling logic accordingly. +- `PointerCancel` has been replaced with `Pointer`, which now has the semantics of an OS touch pointer cancel event. +- `InputMove` and `InputPress` have been merged into `PointerInput`. The use remains exactly the same. +- Picking interaction events are now only accessible through observers, and no `EventReader`. This functionality may be re-implemented later. + +For users of `bevy_winit`: + +- The event `bevy_winit::WinitEvent` has moved to `bevy_window::WindowEvent`. If this was the only thing you depended on `bevy_winit` for, you should switch your dependency to `bevy_window`. +- `bevy_window` now depends on `bevy_input`. The dependencies of `bevy_input` are a subset of the existing dependencies for `bevy_window` so this should be non-breaking. diff --git a/release-content/0.15/migration-guides/14881_Allow_ordering_variable_timesteps_around_fixed_timesteps.md b/release-content/0.15/migration-guides/14881_Allow_ordering_variable_timesteps_around_fixed_timesteps.md new file mode 100644 index 0000000000..6f15fbe169 --- /dev/null +++ b/release-content/0.15/migration-guides/14881_Allow_ordering_variable_timesteps_around_fixed_timesteps.md @@ -0,0 +1,19 @@ +[run_fixed_main_schedule](https://docs.rs/bevy/latest/bevy/time/fn.run_fixed_main_schedule.html) is no longer public. If you used to order against it, use the new dedicated `RunFixedMainLoopSystem` system set instead. You can replace your usage of `run_fixed_main_schedule` one for one by `RunFixedMainLoopSystem::FixedMainLoop`, but it is now more idiomatic to place your systems in either `RunFixedMainLoopSystem::BeforeFixedMainLoop` or `RunFixedMainLoopSystem::AfterFixedMainLoop` + +Old: + +```rust +app.add_systems( + RunFixedMainLoop, + some_system.before(run_fixed_main_schedule) +); +``` + +New: + +```rust +app.add_systems( + RunFixedMainLoop, + some_system.in_set(RunFixedMainLoopSystem::BeforeFixedMainLoop) +); +``` diff --git a/release-content/0.15/migration-guides/14886_Update_Grid_Gizmo_to_use_Color.md b/release-content/0.15/migration-guides/14886_Update_Grid_Gizmo_to_use_Color.md new file mode 100644 index 0000000000..4ac9305216 --- /dev/null +++ b/release-content/0.15/migration-guides/14886_Update_Grid_Gizmo_to_use_Color.md @@ -0,0 +1 @@ +This shouldn’t be adding anything that isn’t already in a migration guide? I assume as it uses `impl Into<...>` in the public interfaces that any users of these APIs shouldn’t have to make any code changes. diff --git a/release-content/0.15/migration-guides/14887_Fix_Gizmos_warnings_and_doc_errors_when_a_subset_of_features.md b/release-content/0.15/migration-guides/14887_Fix_Gizmos_warnings_and_doc_errors_when_a_subset_of_features.md new file mode 100644 index 0000000000..f9a397193b --- /dev/null +++ b/release-content/0.15/migration-guides/14887_Fix_Gizmos_warnings_and_doc_errors_when_a_subset_of_features.md @@ -0,0 +1 @@ +There shouldn’t be any reason to migrate, although if for some reason you use `GizmoMeshConfig` and `bevy_render` but not `bevy_pbr` or `bevy_sprite` (such that it does nothing), then you will get an error that it no longer exists. diff --git a/release-content/0.15/migration-guides/14893_Fix_underflow_panic_in_InitTriInfo.md b/release-content/0.15/migration-guides/14893_Fix_underflow_panic_in_InitTriInfo.md new file mode 100644 index 0000000000..200e2755d3 --- /dev/null +++ b/release-content/0.15/migration-guides/14893_Fix_underflow_panic_in_InitTriInfo.md @@ -0,0 +1 @@ +- No breaking changes introduced. diff --git a/release-content/0.15/migration-guides/14909_Refactor_AsBindGroup_to_use_a_associated_SystemParam.md b/release-content/0.15/migration-guides/14909_Refactor_AsBindGroup_to_use_a_associated_SystemParam.md new file mode 100644 index 0000000000..d906cea462 --- /dev/null +++ b/release-content/0.15/migration-guides/14909_Refactor_AsBindGroup_to_use_a_associated_SystemParam.md @@ -0,0 +1 @@ +`AsBindGroup` now allows the user to specify a `SystemParam` to be used for creating bind groups. diff --git a/release-content/0.15/migration-guides/14910_Rename_Commandsregister_one_shot_system__register_system.md b/release-content/0.15/migration-guides/14910_Rename_Commandsregister_one_shot_system__register_system.md new file mode 100644 index 0000000000..2a6bf3d483 --- /dev/null +++ b/release-content/0.15/migration-guides/14910_Rename_Commandsregister_one_shot_system__register_system.md @@ -0,0 +1 @@ +`Commands::register_one_shot_system` has been renamed to `register_system`. diff --git a/release-content/0.15/migration-guides/14916_Make_TrackedRenderPassset_vertex_buffer_aware_of_slice_size.md b/release-content/0.15/migration-guides/14916_Make_TrackedRenderPassset_vertex_buffer_aware_of_slice_size.md new file mode 100644 index 0000000000..7a7c7cd364 --- /dev/null +++ b/release-content/0.15/migration-guides/14916_Make_TrackedRenderPassset_vertex_buffer_aware_of_slice_size.md @@ -0,0 +1 @@ +- `TrackedRenderPass::set_vertex_buffer` function has been modified to update vertex buffers when the same buffer with the same offset is provided, but its size has changed. Some existing code may rely on the previous behavior, which did not update the vertex buffer in this scenario. diff --git a/release-content/0.15/migration-guides/14926_rename_Drop_to_bevypickingeventsDragDrop_to_unclash_stdops.md b/release-content/0.15/migration-guides/14926_rename_Drop_to_bevypickingeventsDragDrop_to_unclash_stdops.md new file mode 100644 index 0000000000..f4bef64add --- /dev/null +++ b/release-content/0.15/migration-guides/14926_rename_Drop_to_bevypickingeventsDragDrop_to_unclash_stdops.md @@ -0,0 +1,2 @@ +- Rename `Drop` to `DragDrop` + - `bevy::picking::events::Drop` is now `bevy::picking::events::DragDrop` diff --git a/release-content/0.15/migration-guides/14964_Migrate_bevy_transform_to_required_components.md b/release-content/0.15/migration-guides/14964_Migrate_bevy_transform_to_required_components.md new file mode 100644 index 0000000000..c56de8c7df --- /dev/null +++ b/release-content/0.15/migration-guides/14964_Migrate_bevy_transform_to_required_components.md @@ -0,0 +1 @@ +Replace all insertions of `GlobalTransform` and/or `TransformBundle` with `Transform` alone. diff --git a/release-content/0.15/migration-guides/14977_Replace_bevy_utilsCowArc_with_atomicow.md b/release-content/0.15/migration-guides/14977_Replace_bevy_utilsCowArc_with_atomicow.md new file mode 100644 index 0000000000..0607d93be4 --- /dev/null +++ b/release-content/0.15/migration-guides/14977_Replace_bevy_utilsCowArc_with_atomicow.md @@ -0,0 +1 @@ +`bevy_utils::CowArc` has moved to a new crate called [atomicow](https://crates.io/crates/atomicow). diff --git a/release-content/0.15/migration-guides/14989_Return_Results_from_Cameras_worldviewport_conversion_metho.md b/release-content/0.15/migration-guides/14989_Return_Results_from_Cameras_worldviewport_conversion_metho.md new file mode 100644 index 0000000000..0ae7f5dbd2 --- /dev/null +++ b/release-content/0.15/migration-guides/14989_Return_Results_from_Cameras_worldviewport_conversion_metho.md @@ -0,0 +1,8 @@ +The following methods on `Camera` now return a `Result` instead of an `Option` so that they can provide more information about failures: + +- `world_to_viewport` +- `world_to_viewport_with_depth` +- `viewport_to_world` +- `viewport_to_world_2d` + +Call `.ok()` on the `Result` to turn it back into an `Option`, or handle the `Result` directly. diff --git a/release-content/0.15/migration-guides/15013_Implement_animation_masks_allowing_fine_control_of_the_tar.md b/release-content/0.15/migration-guides/15013_Implement_animation_masks_allowing_fine_control_of_the_tar.md new file mode 100644 index 0000000000..e4cb3dcc31 --- /dev/null +++ b/release-content/0.15/migration-guides/15013_Implement_animation_masks_allowing_fine_control_of_the_tar.md @@ -0,0 +1 @@ +- The serialized format of animation graphs has changed with the addition of animation masks. To upgrade animation graph RON files, add `mask` and `mask_groups` fields as appropriate. (They can be safely set to zero.) diff --git a/release-content/0.15/migration-guides/15035_Rename_rendering_components_for_improved_consistency_and_c.md b/release-content/0.15/migration-guides/15035_Rename_rendering_components_for_improved_consistency_and_c.md new file mode 100644 index 0000000000..899c759de1 --- /dev/null +++ b/release-content/0.15/migration-guides/15035_Rename_rendering_components_for_improved_consistency_and_c.md @@ -0,0 +1,13 @@ +Many rendering components have been renamed for improved consistency and clarity. + +- `AutoExposureSettings` → `AutoExposure` +- `BloomSettings` → `Bloom` +- `BloomPrefilterSettings` → `BloomPrefilter` +- `ContrastAdaptiveSharpeningSettings` → `ContrastAdaptiveSharpening` +- `DepthOfFieldSettings` → `DepthOfField` +- `FogSettings` → `DistanceFog` +- `SmaaSettings` → `Smaa` +- `TemporalAntiAliasSettings` → `TemporalAntiAliasing` +- `ScreenSpaceAmbientOcclusionSettings` → `ScreenSpaceAmbientOcclusion` +- `ScreenSpaceReflectionsSettings` → `ScreenSpaceReflections` +- `VolumetricFogSettings` → `VolumetricFog` diff --git a/release-content/0.15/migration-guides/15039_Remove_remnant_EntityHash_and_related_types_from_bevy_util.md b/release-content/0.15/migration-guides/15039_Remove_remnant_EntityHash_and_related_types_from_bevy_util.md new file mode 100644 index 0000000000..c27b6f4bf3 --- /dev/null +++ b/release-content/0.15/migration-guides/15039_Remove_remnant_EntityHash_and_related_types_from_bevy_util.md @@ -0,0 +1 @@ +- Uses of `bevy::utils::{EntityHash, EntityHasher, EntityHashMap, EntityHashSet}` now have to be imported from `bevy::ecs::entity`. diff --git a/release-content/0.15/migration-guides/15073_Split_OrthographicProjectiondefault_into_2d__3d_Adopted.md b/release-content/0.15/migration-guides/15073_Split_OrthographicProjectiondefault_into_2d__3d_Adopted.md new file mode 100644 index 0000000000..2156d379b3 --- /dev/null +++ b/release-content/0.15/migration-guides/15073_Split_OrthographicProjectiondefault_into_2d__3d_Adopted.md @@ -0,0 +1,17 @@ +- In initialization of `OrthographicProjection`, change `..default()` to `..OrthographicProjection::default_2d()` or `..OrthographicProjection::default_3d()` + +Example: + +```diff +--- a/examples/3d/orthographic.rs ++++ b/examples/3d/orthographic.rs +@@ -20,7 +20,7 @@ fn setup( + projection: OrthographicProjection { + scale: 3.0, + scaling_mode: ScalingMode::FixedVertical(2.0), +- ..default() ++ ..OrthographicProjection::default_3d() + } + .into(), + transform: Transform::from_xyz(5.0, 5.0, 5.0).looking_at(Vec3::ZERO, Vec3::Y), +``` diff --git a/release-content/0.15/migration-guides/15075_Remove_OrthographicProjectionscale_adopted.md b/release-content/0.15/migration-guides/15075_Remove_OrthographicProjectionscale_adopted.md new file mode 100644 index 0000000000..530b8f0e06 --- /dev/null +++ b/release-content/0.15/migration-guides/15075_Remove_OrthographicProjectionscale_adopted.md @@ -0,0 +1,13 @@ +Replace all uses of `scale` with `scaling_mode`, keeping in mind that `scale` is (was) a multiplier. For example, replace + +```rust + scale: 2.0, + scaling_mode: ScalingMode::FixedHorizontal(4.0), + +``` + +with + +```rust + scaling_mode: ScalingMode::FixedHorizontal(8.0), +``` diff --git a/release-content/0.15/migration-guides/15089__EntityRefMut_get_components_immutable_variants_only.md b/release-content/0.15/migration-guides/15089__EntityRefMut_get_components_immutable_variants_only.md new file mode 100644 index 0000000000..64d400b468 --- /dev/null +++ b/release-content/0.15/migration-guides/15089__EntityRefMut_get_components_immutable_variants_only.md @@ -0,0 +1 @@ +- Renamed `FilteredEntityRef::components` to `FilteredEntityRef::accessed_components` and `FilteredEntityMut::components` to `FilteredEntityMut::accessed_components`. diff --git a/release-content/0.15/migration-guides/15107_bevy_reflect_Refactor_serde_module.md b/release-content/0.15/migration-guides/15107_bevy_reflect_Refactor_serde_module.md new file mode 100644 index 0000000000..d886420153 --- /dev/null +++ b/release-content/0.15/migration-guides/15107_bevy_reflect_Refactor_serde_module.md @@ -0,0 +1,27 @@ +The fields on `ReflectSerializer` and `TypedReflectSerializer` are now private. To instantiate, the corresponding constructor must be used: + +```rust +// BEFORE +let serializer = ReflectSerializer { + value: &my_value, + registry: &type_registry, +}; + +// AFTER +let serializer = ReflectSerializer::new(&my_value, &type_registry); +``` + +Additionally, the following types are no longer public: + +- `ArraySerializer` +- `EnumSerializer` +- `ListSerializer` +- `MapSerializer` +- `ReflectValueSerializer` (fully removed) +- `StructSerializer` +- `TupleSerializer` +- `TupleStructSerializer` + +As well as the following traits: + +- `DeserializeValue` (fully removed) diff --git a/release-content/0.15/migration-guides/15108_bevy_reflect_Add_DynamicTyped_trait.md b/release-content/0.15/migration-guides/15108_bevy_reflect_Add_DynamicTyped_trait.md new file mode 100644 index 0000000000..e8af46a281 --- /dev/null +++ b/release-content/0.15/migration-guides/15108_bevy_reflect_Add_DynamicTyped_trait.md @@ -0,0 +1 @@ +`Reflect` now has a supertrait of `DynamicTyped`. If you were manually implementing `Reflect` and did not implement `Typed`, you will now need to do so. diff --git a/release-content/0.15/migration-guides/15126_Remove_ReceivedCharacter.md b/release-content/0.15/migration-guides/15126_Remove_ReceivedCharacter.md new file mode 100644 index 0000000000..5b0e07dcdd --- /dev/null +++ b/release-content/0.15/migration-guides/15126_Remove_ReceivedCharacter.md @@ -0,0 +1,32 @@ +`ReceivedCharacter` was deprecated in 0.14 due to `winit` reworking their keyboard system. It has now been fully removed. Switch to using `KeyboardInput` instead. + +```rust +// 0.14 +fn listen_characters(events: EventReader) { + for event in events.read() { + info!("{}", event.char); + } +} + +// 0.15 +fn listen_characters(events: EventReader) { + for event in events.read() { + // Only check for characters when the key is pressed. + if !event.state.is_pressed() { + continue; + } + + // Note that some keys such as `Space` and `Tab` won't be detected as a character. + // Instead, check for them as separate enum variants. + match &event.logical_key { + Key::Character(character) => { + info!("{} pressed.", character); + }, + Key::Space => { + info!("Space pressed."); + }, + _ => {}, + } + } +} +``` diff --git a/release-content/0.15/migration-guides/15151_Removed_Type_Parameters_from_Observer.md b/release-content/0.15/migration-guides/15151_Removed_Type_Parameters_from_Observer.md new file mode 100644 index 0000000000..a6c9d38ef3 --- /dev/null +++ b/release-content/0.15/migration-guides/15151_Removed_Type_Parameters_from_Observer.md @@ -0,0 +1 @@ +If you filtered for observers using `Observer`, instead filter for an `Observer`. diff --git a/release-content/0.15/migration-guides/15163_use_precomputed_border_values.md b/release-content/0.15/migration-guides/15163_use_precomputed_border_values.md new file mode 100644 index 0000000000..c417537c93 --- /dev/null +++ b/release-content/0.15/migration-guides/15163_use_precomputed_border_values.md @@ -0,0 +1,3 @@ +The `logical_rect` and `physical_rect` methods have been removed from `Node`. Use `Rect::from_center_size` with the translation and node size instead. + +The types of the fields border and border_radius of `ExtractedUiNode` have been changed to `BorderRect` and `ResolvedBorderRadius` respectively. diff --git a/release-content/0.15/migration-guides/15174_Use_FromReflect_when_extracting_entities_in_dynamic_scenes.md b/release-content/0.15/migration-guides/15174_Use_FromReflect_when_extracting_entities_in_dynamic_scenes.md new file mode 100644 index 0000000000..848b1ce9c4 --- /dev/null +++ b/release-content/0.15/migration-guides/15174_Use_FromReflect_when_extracting_entities_in_dynamic_scenes.md @@ -0,0 +1,60 @@ +The `DynamicScene` format is changed to use custom serialize impls so old scene files will need updating: + +Old: + +```ron +( + resources: {}, + entities: { + 4294967299: ( + components: { + "bevy_render::camera::projection::OrthographicProjection": ( + near: 0.0, + far: 1000.0, + viewport_origin: ( + x: 0.5, + y: 0.5, + ), + scaling_mode: WindowSize(1.0), + scale: 1.0, + area: ( + min: ( + x: -1.0, + y: -1.0, + ), + max: ( + x: 1.0, + y: 1.0, + ), + ), + ), + }, + ), + }, +) +``` + +New: + +```ron +( + resources: {}, + entities: { + 4294967299: ( + components: { + "bevy_render::camera::projection::OrthographicProjection": ( + near: 0.0, + far: 1000.0, + viewport_origin: (0.5, 0.5), + scaling_mode: WindowSize(1.0), + scale: 1.0, + area: ( + min: (-1.0, -1.0), + max: (1.0, 1.0), + ), + ), + }, + ), + }, +) +``` diff --git a/release-content/0.15/migration-guides/15184_Support_systems_that_take_references_as_input.md b/release-content/0.15/migration-guides/15184_Support_systems_that_take_references_as_input.md new file mode 100644 index 0000000000..7ea3e18b8c --- /dev/null +++ b/release-content/0.15/migration-guides/15184_Support_systems_that_take_references_as_input.md @@ -0,0 +1,7 @@ +- All current explicit usages of the following types must be changed in the way specified: + - `SystemId` to `SystemId, O>` + - `System` to `System>` + - `IntoSystem` to `IntoSystem, O, M>` + - `Condition` to `Condition>` + +- `In>` is no longer a valid input parameter type. Use `Trigger` directly, instead. diff --git a/release-content/0.15/migration-guides/15196_Rename_push_children_to_add_children.md b/release-content/0.15/migration-guides/15196_Rename_push_children_to_add_children.md new file mode 100644 index 0000000000..842a51f84e --- /dev/null +++ b/release-content/0.15/migration-guides/15196_Rename_push_children_to_add_children.md @@ -0,0 +1,7 @@ +> +This section is optional. If there are no breaking changes, you can delete this section. + + +- If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes + +rename any use of `push_children()` to the updated `add_children()` diff --git a/release-content/0.15/migration-guides/15210_explicitly_mention_component_in_methods_on_DynamicSceneBuilder.md b/release-content/0.15/migration-guides/15210_explicitly_mention_component_in_methods_on_DynamicSceneBuilder.md new file mode 100644 index 0000000000..11ea831985 --- /dev/null +++ b/release-content/0.15/migration-guides/15210_explicitly_mention_component_in_methods_on_DynamicSceneBuilder.md @@ -0,0 +1,7 @@ +`DynamicSceneBuilder::allow_all` and `deny_all` now set resource accesses, not just components. To return to the previous behavior, use the new `allow_all_components` or `deny_all_components` methods. + +The following methods for `DynamicSceneBuilder` have been renamed: + +- `with_filter` -> `with_component_filter` +- `allow` -> `allow_component` +- `deny` -> `deny_component` diff --git a/release-content/0.15/migration-guides/15234_Rename_Add_to_Queue_for_methods_with_deferred_semantics.md b/release-content/0.15/migration-guides/15234_Rename_Add_to_Queue_for_methods_with_deferred_semantics.md new file mode 100644 index 0000000000..39ab86ab18 --- /dev/null +++ b/release-content/0.15/migration-guides/15234_Rename_Add_to_Queue_for_methods_with_deferred_semantics.md @@ -0,0 +1,2 @@ +- `Commands::add` and `Commands::push` have been replaced with `Commands::queue`. +- `ChildBuilder::add_command` has been renamed to `ChildBuilder::queue_command`. diff --git a/release-content/0.15/migration-guides/15237_AssetServer_LoadState_API_consistency.md b/release-content/0.15/migration-guides/15237_AssetServer_LoadState_API_consistency.md new file mode 100644 index 0000000000..cf873b4c07 --- /dev/null +++ b/release-content/0.15/migration-guides/15237_AssetServer_LoadState_API_consistency.md @@ -0,0 +1 @@ + diff --git a/release-content/0.15/migration-guides/15239_Fix_floating_point_math.md b/release-content/0.15/migration-guides/15239_Fix_floating_point_math.md new file mode 100644 index 0000000000..d938ab4eb3 --- /dev/null +++ b/release-content/0.15/migration-guides/15239_Fix_floating_point_math.md @@ -0,0 +1,2 @@ +- Not a breaking change +- Projects should use bevy math where applicable diff --git a/release-content/0.15/migration-guides/15240_bevy_reflect_Replace_value_terminology_with_opaque.md b/release-content/0.15/migration-guides/15240_bevy_reflect_Replace_value_terminology_with_opaque.md new file mode 100644 index 0000000000..5df601349a --- /dev/null +++ b/release-content/0.15/migration-guides/15240_bevy_reflect_Replace_value_terminology_with_opaque.md @@ -0,0 +1,27 @@ +The reflection concept of “value type” has been replaced with a clearer “opaque type”. The following renames have been made to account for this: + +- `ReflectKind::Value` → `ReflectKind::Opaque` +- `ReflectRef::Value` → `ReflectRef::Opaque` +- `ReflectMut::Value` → `ReflectMut::Opaque` +- `ReflectOwned::Value` → `ReflectOwned::Opaque` +- `TypeInfo::Value` → `TypeInfo::Opaque` +- `ValueInfo` → `OpaqueInfo` +- `impl_reflect_value!` → `impl_reflect_opaque!` +- `impl_from_reflect_value!` → `impl_from_reflect_opaque!` + +Additionally, declaring your own opaque types no longer uses `#[reflect_value]`. This attribute has been replaced by `#[reflect(opaque)]`: + +```rust +// BEFORE +#[derive(Reflect)] +#[reflect_value(Default)] +struct MyOpaqueType(u32); + +// AFTER +#[derive(Reflect)] +#[reflect(opaque)] +#[reflect(Default)] +struct MyOpaqueType(u32); +``` + +Note that the order in which `#[reflect(opaque)]` appears does not matter. diff --git a/release-content/0.15/migration-guides/15263_change_return_type_of_Worldresource_ref_to_Ref.md b/release-content/0.15/migration-guides/15263_change_return_type_of_Worldresource_ref_to_Ref.md new file mode 100644 index 0000000000..bbb7f32c0a --- /dev/null +++ b/release-content/0.15/migration-guides/15263_change_return_type_of_Worldresource_ref_to_Ref.md @@ -0,0 +1,21 @@ +Previously `World::get_resource_ref::` and `World::resource_ref::` would return a `Res` which was inconsistent with the rest of the `World` API (notably `resource_scope`). This has been fixed and the methods now return `Ref`. + +This means it is no longer possible to get `Res` from `World`. If you were relying on this, you should try using `Ref` instead since it has the same functionality. + +__Before__ + +```rust +let my_resource: Res = world.resource_ref(); +function_taking_resource(my_resource); + +fn function_taking_resource(resource: Res) { /* ... */ } +``` + +__After__ + +```rust +let my_resource: Ref = world.resource_ref(); +function_taking_resource(my_resource); + +fn function_taking_resource(resource: Ref) { /* ... */ } +``` diff --git a/release-content/0.15/migration-guides/15279_Allow_bevy_utils_in_no_std_Contexts.md b/release-content/0.15/migration-guides/15279_Allow_bevy_utils_in_no_std_Contexts.md new file mode 100644 index 0000000000..6c0fbb742b --- /dev/null +++ b/release-content/0.15/migration-guides/15279_Allow_bevy_utils_in_no_std_Contexts.md @@ -0,0 +1 @@ +If you were importing `bevy_utils` and setting `default_features` to `false`, but relying on elements which are now gated behind the `std` or `alloc` features, include the relevant feature in your `Cargo.toml`. diff --git a/release-content/0.15/migration-guides/15281_Add_core_and_alloc_over_std_Lints.md b/release-content/0.15/migration-guides/15281_Add_core_and_alloc_over_std_Lints.md new file mode 100644 index 0000000000..a5b0f873a2 --- /dev/null +++ b/release-content/0.15/migration-guides/15281_Add_core_and_alloc_over_std_Lints.md @@ -0,0 +1 @@ +The MSRV is now 1.81. Please update to this version or higher. diff --git a/release-content/0.15/migration-guides/15282_Allow_animation_clips_to_animate_arbitrary_properties.md b/release-content/0.15/migration-guides/15282_Allow_animation_clips_to_animate_arbitrary_properties.md new file mode 100644 index 0000000000..e549ff4bcc --- /dev/null +++ b/release-content/0.15/migration-guides/15282_Allow_animation_clips_to_animate_arbitrary_properties.md @@ -0,0 +1 @@ +- Animation keyframes are now an extensible trait, not an enum. Replace `Keyframes::Translation(...)`, `Keyframes::Scale(...)`, `Keyframes::Rotation(...)`, and `Keyframes::Weights(...)` with `Box::new(TranslationKeyframes(...))`, `Box::new(ScaleKeyframes(...))`, `Box::new(RotationKeyframes(...))`, and `Box::new(MorphWeightsKeyframes(...))` respectively. diff --git a/release-content/0.15/migration-guides/15294_Remove_allocation_in_get_short_name.md b/release-content/0.15/migration-guides/15294_Remove_allocation_in_get_short_name.md new file mode 100644 index 0000000000..6e9448f789 --- /dev/null +++ b/release-content/0.15/migration-guides/15294_Remove_allocation_in_get_short_name.md @@ -0,0 +1,19 @@ +__For `format!`, `dbg!`, `panic!`, etc.__ + +```rust +// Before +panic!("{} is too short!", get_short_name(name)); + +// After +panic!("{} is too short!", ShortName(name)); +``` + +__Need a `String` Value__ + +```rust +// Before +let short: String = get_short_name(name); + +// After +let short: String = ShortName(name).to_string(); +``` diff --git a/release-content/0.15/migration-guides/15340_move_ShortName_to_bevy_reflect.md b/release-content/0.15/migration-guides/15340_move_ShortName_to_bevy_reflect.md new file mode 100644 index 0000000000..7caccc97c3 --- /dev/null +++ b/release-content/0.15/migration-guides/15340_move_ShortName_to_bevy_reflect.md @@ -0,0 +1 @@ +- References to `bevy_utils::ShortName` should instead now be `bevy_reflect::ShortName`. diff --git a/release-content/0.15/migration-guides/15341_Add_UI_GhostNode.md b/release-content/0.15/migration-guides/15341_Add_UI_GhostNode.md new file mode 100644 index 0000000000..9a795a9598 --- /dev/null +++ b/release-content/0.15/migration-guides/15341_Add_UI_GhostNode.md @@ -0,0 +1,3 @@ +Any code that previously relied on `Parent`/`Children` to iterate UI children may now want to use `bevy_ui::UiChildren` to ensure ghost nodes are skipped, and their first descendant Nodes included. + +UI root nodes may now be children of ghost nodes, which means `Without` might not query all root nodes. Use `bevy_ui::UiRootNodes` where needed to iterate root nodes instead. diff --git a/release-content/0.15/migration-guides/15344_Split_TextureAtlasSources_out_of_TextureAtlasLayout_and_ma.md b/release-content/0.15/migration-guides/15344_Split_TextureAtlasSources_out_of_TextureAtlasLayout_and_ma.md new file mode 100644 index 0000000000..839b12fae8 --- /dev/null +++ b/release-content/0.15/migration-guides/15344_Split_TextureAtlasSources_out_of_TextureAtlasLayout_and_ma.md @@ -0,0 +1,40 @@ +`TextureAtlasBuilder` no longer stores a mapping back to the original images in `TextureAtlasLayout`; that functionality has been added to a new struct, `TextureAtlasSources`, instead. This also means that the signature for `TextureAtlasBuilder::finish` has changed, meaning that calls of the form: + +```rust +let (atlas_layout, image) = builder.build()?; +``` + +Will now change to the form: + +```rust +let (atlas_layout, atlas_sources, image) = builder.build()?; +``` + +And instead of performing a reverse-lookup from the layout, like so: + +```rust +let atlas_layout_handle = texture_atlases.add(atlas_layout.clone()); +let index = atlas_layout.get_texture_index(&my_handle); +let handle = TextureAtlas { + layout: atlas_layout_handle, + index, +}; +``` + +You can perform the lookup from the sources instead: + +```rust +let atlas_layout = texture_atlases.add(atlas_layout); +let index = atlas_sources.get_texture_index(&my_handle); +let handle = TextureAtlas { + layout: atlas_layout, + index, +}; +``` + +Additionally, `TextureAtlasSources` also has a convenience method, `handle`, which directly combines the index and an existing `TextureAtlasLayout` handle into a new `TextureAtlas`: + +```rust +let atlas_layout = texture_atlases.add(atlas_layout); +let handle = atlas_sources.handle(atlas_layout, &my_handle); +``` diff --git a/release-content/0.15/migration-guides/15368_Add_the_ability_to_control_font_smoothing.md b/release-content/0.15/migration-guides/15368_Add_the_ability_to_control_font_smoothing.md new file mode 100644 index 0000000000..5c5ee88cb6 --- /dev/null +++ b/release-content/0.15/migration-guides/15368_Add_the_ability_to_control_font_smoothing.md @@ -0,0 +1,7 @@ +- `Text` now contains a `font_smoothing: FontSmoothing` property, make sure to include it or add `..default()` when using the struct directly; +- `FontSizeKey` has been renamed to `FontAtlasKey`, and now also contains the `FontSmoothing` setting; +- The following methods now take an extra `font_smoothing: FontSmoothing` argument: + - `FontAtlas::new()` + - `FontAtlasSet::add_glyph_to_atlas()` + - `FontAtlasSet::get_glyph_atlas_info()` + - `FontAtlasSet::get_outlined_glyph_texture()` diff --git a/release-content/0.15/migration-guides/15372_Use_crate_disqualified.md b/release-content/0.15/migration-guides/15372_Use_crate_disqualified.md new file mode 100644 index 0000000000..d659fa012c --- /dev/null +++ b/release-content/0.15/migration-guides/15372_Use_crate_disqualified.md @@ -0,0 +1 @@ +Replace references to `bevy_utils::ShortName` with `disqualified::ShortName`. diff --git a/release-content/0.15/migration-guides/15385_Bubbling_observers_traversal_should_use_query_data.md b/release-content/0.15/migration-guides/15385_Bubbling_observers_traversal_should_use_query_data.md new file mode 100644 index 0000000000..fb485ba79b --- /dev/null +++ b/release-content/0.15/migration-guides/15385_Bubbling_observers_traversal_should_use_query_data.md @@ -0,0 +1 @@ +Update implementations of `Traversal`. diff --git a/release-content/0.15/migration-guides/15402_bevy_reflect_Update_EulerRot_to_match_glam_029.md b/release-content/0.15/migration-guides/15402_bevy_reflect_Update_EulerRot_to_match_glam_029.md new file mode 100644 index 0000000000..0c5bdc741d --- /dev/null +++ b/release-content/0.15/migration-guides/15402_bevy_reflect_Update_EulerRot_to_match_glam_029.md @@ -0,0 +1 @@ +The reflection implementation for `EulerRot` has been updated to align with `glam` 0.29. Please update any reflection-based usages accordingly. diff --git a/release-content/0.15/migration-guides/15406_Make_drain_take_a_mutable_borrow_instead_of_BoxSelf_for_re.md b/release-content/0.15/migration-guides/15406_Make_drain_take_a_mutable_borrow_instead_of_BoxSelf_for_re.md new file mode 100644 index 0000000000..c031a81ae0 --- /dev/null +++ b/release-content/0.15/migration-guides/15406_Make_drain_take_a_mutable_borrow_instead_of_BoxSelf_for_re.md @@ -0,0 +1 @@ +- `reflect::Map`, `reflect::List`, and `reflect::Set` all now take a `&mut self` instead of a `Box`. Callers of these traits should add `&mut` before their boxes, and implementers of these traits should update to match. diff --git a/release-content/0.15/migration-guides/15410_Follow_up_to_cached_run_system.md b/release-content/0.15/migration-guides/15410_Follow_up_to_cached_run_system.md new file mode 100644 index 0000000000..e465f7bdad --- /dev/null +++ b/release-content/0.15/migration-guides/15410_Follow_up_to_cached_run_system.md @@ -0,0 +1 @@ +- `IntoSystem::pipe` and `IntoSystem::map` now return `IntoPipeSystem` and `IntoAdapterSystem` instead of `PipeSystem` and `AdapterSystem`. Most notably these types don’t implement `System` but rather only `IntoSystem`. diff --git a/release-content/0.15/migration-guides/15422_Change_ReflectMapEntities_to_operate_on_components_before_.md b/release-content/0.15/migration-guides/15422_Change_ReflectMapEntities_to_operate_on_components_before_.md new file mode 100644 index 0000000000..cbd09a103b --- /dev/null +++ b/release-content/0.15/migration-guides/15422_Change_ReflectMapEntities_to_operate_on_components_before_.md @@ -0,0 +1,2 @@ +- Consumers of `ReflectMapEntities` will need to call `map_entities` on values prior to inserting them into the world. +- Implementors of `MapEntities` will need to remove the `mappings` method, which is no longer needed for `ReflectMapEntities` and has been removed from the trait. diff --git a/release-content/0.15/migration-guides/15434_Curvebased_animation.md b/release-content/0.15/migration-guides/15434_Curvebased_animation.md new file mode 100644 index 0000000000..29a7b27ddb --- /dev/null +++ b/release-content/0.15/migration-guides/15434_Curvebased_animation.md @@ -0,0 +1,46 @@ +Most user code that does not directly deal with `AnimationClip` and `VariableCurve` will not need to be changed. On the other hand, `VariableCurve` has been completely overhauled. If you were previously defining animation curves in code using keyframes, you will need to migrate that code to use curve constructors instead. For example, a rotation animation defined using keyframes and added to an animation clip like this: + +```rust +animation_clip.add_curve_to_target( + animation_target_id, + VariableCurve { + keyframe_timestamps: vec![0.0, 1.0, 2.0, 3.0, 4.0], + keyframes: Keyframes::Rotation(vec![ + Quat::IDENTITY, + Quat::from_axis_angle(Vec3::Y, PI / 2.), + Quat::from_axis_angle(Vec3::Y, PI / 2. * 2.), + Quat::from_axis_angle(Vec3::Y, PI / 2. * 3.), + Quat::IDENTITY, + ]), + interpolation: Interpolation::Linear, + }, +); +``` + +would now be added like this: + +```rust +animation_clip.add_curve_to_target( + animation_target_id, + AnimatableKeyframeCurve::new([0.0, 1.0, 2.0, 3.0, 4.0].into_iter().zip([ + Quat::IDENTITY, + Quat::from_axis_angle(Vec3::Y, PI / 2.), + Quat::from_axis_angle(Vec3::Y, PI / 2. * 2.), + Quat::from_axis_angle(Vec3::Y, PI / 2. * 3.), + Quat::IDENTITY, + ])) + .map(RotationCurve) + .expect("Failed to build rotation curve"), +); +``` + +Note that the interface of `AnimationClip::add_curve_to_target` has also changed (as this example shows, if subtly), and now takes its curve input as an `impl AnimationCurve`. If you need to add a `VariableCurve` directly, a new method `add_variable_curve_to_target` accommodates that (and serves as a one-to-one migration in this regard). + +__For reviewers__ + +The diff is pretty big, and the structure of some of the changes might not be super-obvious: + +- `keyframes.rs` became `animation_curves.rs`, and `AnimationCurve` is based heavily on `Keyframes`, with the adaptors also largely following suite. +- The Curve API adaptor structs were moved from `bevy_math::curve::mod` into their own module `adaptors`. There are no functional changes to how these adaptors work; this is just to make room for the specialized reflection implementations since `mod.rs` was getting kind of cramped. +- The new module `gltf_curves` holds the additional curve constructions that are needed by the glTF loader. Note that the loader uses a mix of these and off-the-shelf `bevy_math` curve stuff. +- `animatable.rs` no longer holds logic related to keyframe interpolation, which is now delegated to the existing abstractions in `bevy_math::curve::cores`. diff --git a/release-content/0.15/migration-guides/15435_List_components_for_QueryEntityErrorQueryDoesNotMatch.md b/release-content/0.15/migration-guides/15435_List_components_for_QueryEntityErrorQueryDoesNotMatch.md new file mode 100644 index 0000000000..ee8873fe13 --- /dev/null +++ b/release-content/0.15/migration-guides/15435_List_components_for_QueryEntityErrorQueryDoesNotMatch.md @@ -0,0 +1 @@ +- `QueryEntityError` now has a lifetime. Convert it to a custom error if you need to store it. diff --git a/release-content/0.15/migration-guides/15442_Clip_to_the_UI_nodes_content_box.md b/release-content/0.15/migration-guides/15442_Clip_to_the_UI_nodes_content_box.md new file mode 100644 index 0000000000..071a854482 --- /dev/null +++ b/release-content/0.15/migration-guides/15442_Clip_to_the_UI_nodes_content_box.md @@ -0,0 +1 @@ +Migration guide is on #15561 diff --git a/release-content/0.15/migration-guides/15454_Rename_init_component__friends.md b/release-content/0.15/migration-guides/15454_Rename_init_component__friends.md new file mode 100644 index 0000000000..bb147cfea7 --- /dev/null +++ b/release-content/0.15/migration-guides/15454_Rename_init_component__friends.md @@ -0,0 +1,7 @@ +- `World::init_component` has been renamed to `register_component`. +- `World::init_component_with_descriptor` has been renamed to `register_component_with_descriptor`. +- `World::init_bundle` has been renamed to `register_bundle`. +- `Components::init_component` has been renamed to `register_component`. +- `Components::init_component_with_descriptor` has been renamed to `register_component_with_descriptor`. +- `Components::init_resource` has been renamed to `register_resource`. +- `Components::init_non_send` had been renamed to `register_non_send`. diff --git a/release-content/0.15/migration-guides/15469_Basic_integration_of_cubic_spline_curves_with_the_Curve_AP.md b/release-content/0.15/migration-guides/15469_Basic_integration_of_cubic_spline_curves_with_the_Curve_AP.md new file mode 100644 index 0000000000..a79408d1ea --- /dev/null +++ b/release-content/0.15/migration-guides/15469_Basic_integration_of_cubic_spline_curves_with_the_Curve_AP.md @@ -0,0 +1 @@ +The `RationalCurve::domain` method has been renamed to `RationalCurve::length`. Calling `.domain()` on a `RationalCurve` now returns its entire domain as an `Interval`. diff --git a/release-content/0.15/migration-guides/15474_Migrate_visibility_to_required_components.md b/release-content/0.15/migration-guides/15474_Migrate_visibility_to_required_components.md new file mode 100644 index 0000000000..32f4532f62 --- /dev/null +++ b/release-content/0.15/migration-guides/15474_Migrate_visibility_to_required_components.md @@ -0,0 +1 @@ +Replace all insertions of `VisibilityBundle` with the `Visibility` component. The other components required by it will now be inserted automatically. diff --git a/release-content/0.15/migration-guides/15484_Remove_ReturnUnit_variant.md b/release-content/0.15/migration-guides/15484_Remove_ReturnUnit_variant.md new file mode 100644 index 0000000000..ef4cb31881 --- /dev/null +++ b/release-content/0.15/migration-guides/15484_Remove_ReturnUnit_variant.md @@ -0,0 +1 @@ +- Removed the `Return::Unit` variant; use `Return::unit()` instead. diff --git a/release-content/0.15/migration-guides/15489_Migrate_bevy_sprite_to_required_components.md b/release-content/0.15/migration-guides/15489_Migrate_bevy_sprite_to_required_components.md new file mode 100644 index 0000000000..da16aa3e21 --- /dev/null +++ b/release-content/0.15/migration-guides/15489_Migrate_bevy_sprite_to_required_components.md @@ -0,0 +1,3 @@ +Replace all uses of `SpriteBundle` with `Sprite`. There are several new convenience constructors: `Sprite::from_image`, `Sprite::from_atlas_image`, `Sprite::from_color`. + +WARNING: use of `Handle` and `TextureAtlas` as components on sprite entities will NO LONGER WORK. Use the fields on `Sprite` instead. I would have removed the `Component` impls from `TextureAtlas` and `Handle` except it is still used within ui. We should fix this moving forward with the migration. diff --git a/release-content/0.15/migration-guides/15509_bevy_asset_Improve_NestedLoader_API.md b/release-content/0.15/migration-guides/15509_bevy_asset_Improve_NestedLoader_API.md new file mode 100644 index 0000000000..a1247ffa69 --- /dev/null +++ b/release-content/0.15/migration-guides/15509_bevy_asset_Improve_NestedLoader_API.md @@ -0,0 +1,6 @@ +Code which uses `bevy_asset`’s `LoadContext::loader` / `NestedLoader` will see some naming changes: + +- `untyped` is replaced by `with_unknown_type` +- `with_asset_type` is replaced by `with_static_type` +- `with_asset_type_id` is replaced by `with_dynamic_type` +- `direct` is replaced by `immediate` (the opposite of “immediate” is “deferred”) diff --git a/release-content/0.15/migration-guides/15524_Migrate_meshes_and_materials_to_required_components.md b/release-content/0.15/migration-guides/15524_Migrate_meshes_and_materials_to_required_components.md new file mode 100644 index 0000000000..f56abd9119 --- /dev/null +++ b/release-content/0.15/migration-guides/15524_Migrate_meshes_and_materials_to_required_components.md @@ -0,0 +1,28 @@ +Asset handles for meshes and mesh materials must now be wrapped in the `Mesh2d` and `MeshMaterial2d` or `Mesh3d` and `MeshMaterial3d` components for 2D and 3D respectively. Raw handles as components no longer render meshes. + +Additionally, `MaterialMesh2dBundle`, `MaterialMeshBundle`, and `PbrBundle` have been deprecated. Instead, use the mesh and material components directly. + +Previously: + +```rust +commands.spawn(MaterialMesh2dBundle { + mesh: meshes.add(Circle::new(100.0)).into(), + material: materials.add(Color::srgb(7.5, 0.0, 7.5)), + transform: Transform::from_translation(Vec3::new(-200., 0., 0.)), + ..default() +}); +``` + +Now: + +```rust +commands.spawn(( + Mesh2d(meshes.add(Circle::new(100.0))), + MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))), + Transform::from_translation(Vec3::new(-200., 0., 0.)), +)); +``` + +If the mesh material is missing, a white default material is now used. Previously, nothing was rendered if the material was missing. + +The `WithMesh2d` and `WithMesh3d` query filter type aliases have also been removed. Simply use `With` or `With`. diff --git a/release-content/0.15/migration-guides/15526_System_param_validation_for_observers_system_registry_and_.md b/release-content/0.15/migration-guides/15526_System_param_validation_for_observers_system_registry_and_.md new file mode 100644 index 0000000000..f1f18ee27a --- /dev/null +++ b/release-content/0.15/migration-guides/15526_System_param_validation_for_observers_system_registry_and_.md @@ -0,0 +1 @@ +- `RunSystemOnce::run_system_once` and `RunSystemOnce::run_system_once_with` now return a `Result` instead of just `Out` diff --git a/release-content/0.15/migration-guides/15546_Cleanup_unneeded_lifetimes_in_bevy_asset.md b/release-content/0.15/migration-guides/15546_Cleanup_unneeded_lifetimes_in_bevy_asset.md new file mode 100644 index 0000000000..8702eeacb9 --- /dev/null +++ b/release-content/0.15/migration-guides/15546_Cleanup_unneeded_lifetimes_in_bevy_asset.md @@ -0,0 +1 @@ +The traits `AssetLoader`, `AssetSaver` and `Process` traits from `bevy_asset` now use elided lifetimes. If you implement these then remove the named lifetime. diff --git a/release-content/0.15/migration-guides/15553_15540_Make_Worldflush_commands_private.md b/release-content/0.15/migration-guides/15553_15540_Make_Worldflush_commands_private.md new file mode 100644 index 0000000000..cf873b4c07 --- /dev/null +++ b/release-content/0.15/migration-guides/15553_15540_Make_Worldflush_commands_private.md @@ -0,0 +1 @@ + diff --git a/release-content/0.15/migration-guides/15554_Migrate_lights_to_required_components.md b/release-content/0.15/migration-guides/15554_Migrate_lights_to_required_components.md new file mode 100644 index 0000000000..8431da0889 --- /dev/null +++ b/release-content/0.15/migration-guides/15554_Migrate_lights_to_required_components.md @@ -0,0 +1 @@ +`PointLightBundle`, `SpotLightBundle`, and `DirectionalLightBundle` have been deprecated. Use the `PointLight`, `SpotLight`, and `DirectionalLight` components instead. Adding them will now insert the other components required by them automatically. diff --git a/release-content/0.15/migration-guides/15561_Overflow_clip_margin.md b/release-content/0.15/migration-guides/15561_Overflow_clip_margin.md new file mode 100644 index 0000000000..05d393ecfd --- /dev/null +++ b/release-content/0.15/migration-guides/15561_Overflow_clip_margin.md @@ -0,0 +1,11 @@ +Style has a new field `OverflowClipMargin`. It allows users to set the visible area for clipped content when using overflow-clip, -hidden, or -scroll and expand it with a margin. + +There are three associated constructor functions `content_box`, `padding_box` and `border_box`: + +- `content_box`: elements painted outside of the content box area (the innermost part of the node excluding the padding and border) of the node are clipped. This is the new default behaviour. +- `padding_box`: elements painted outside outside of the padding area of the node are clipped. +- `border_box`: elements painted outside of the bounds of the node are clipped. This matches the behaviour from Bevy 0.14. + +There is also a `with_margin` method that increases the size of the visible area by the given number in logical pixels, negative margin values are clamped to zero. + +`OverflowClipMargin` is ignored unless overflow-clip, -hidden or -scroll is also set on at least one axis of the UI node. diff --git a/release-content/0.15/migration-guides/15566_Fix_Mesh_allocator_bug_and_reduce_Mesh_data_copies_by_two.md b/release-content/0.15/migration-guides/15566_Fix_Mesh_allocator_bug_and_reduce_Mesh_data_copies_by_two.md new file mode 100644 index 0000000000..42f137a4b0 --- /dev/null +++ b/release-content/0.15/migration-guides/15566_Fix_Mesh_allocator_bug_and_reduce_Mesh_data_copies_by_two.md @@ -0,0 +1 @@ +- `Mesh::get_vertex_buffer_data` has been renamed `Mesh::create_packed_vertex_buffer_data` to reflect the fact that it copies data and allocates. diff --git a/release-content/0.15/migration-guides/15568_Migrate_fog_volumes_to_required_components.md b/release-content/0.15/migration-guides/15568_Migrate_fog_volumes_to_required_components.md new file mode 100644 index 0000000000..a8ce507b07 --- /dev/null +++ b/release-content/0.15/migration-guides/15568_Migrate_fog_volumes_to_required_components.md @@ -0,0 +1 @@ +Replace all insertions of `FogVolumeBundle` with the `Visibility` component. The other components required by it will now be inserted automatically. diff --git a/release-content/0.15/migration-guides/15572_Migrate_motion_blur_TAA_SSAO_and_SSR_to_required_component.md b/release-content/0.15/migration-guides/15572_Migrate_motion_blur_TAA_SSAO_and_SSR_to_required_component.md new file mode 100644 index 0000000000..6198edcb24 --- /dev/null +++ b/release-content/0.15/migration-guides/15572_Migrate_motion_blur_TAA_SSAO_and_SSR_to_required_component.md @@ -0,0 +1 @@ +`MotionBlurBundle`, `TemporalAntiAliasBundle`, `ScreenSpaceAmbientOcclusionBundle`, and `ScreenSpaceReflectionsBundle` have been deprecated in favor of the `MotionBlur`, `TemporalAntiAliasing`, `ScreenSpaceAmbientOcclusion`, and `ScreenSpaceReflections` components instead. Inserting them will now also insert the other components required by them automatically. diff --git a/release-content/0.15/migration-guides/15573_Migrate_audio_to_required_components.md b/release-content/0.15/migration-guides/15573_Migrate_audio_to_required_components.md new file mode 100644 index 0000000000..23fdd5c09d --- /dev/null +++ b/release-content/0.15/migration-guides/15573_Migrate_audio_to_required_components.md @@ -0,0 +1,7 @@ +Replace all insertions of `AudioSourceBundle`, `AudioBundle`, and `PitchBundle` with the `AudioPlayer` component. The other components required by it will now be inserted automatically. + +In cases where the generics cannot be inferred, you may need to specify them explicitly. For example: + +```rust +commands.spawn(AudioPlayer::(asset_server.load("sounds/sick_beats.ogg"))); +``` diff --git a/release-content/0.15/migration-guides/15579_Migrate_scenes_to_required_components.md b/release-content/0.15/migration-guides/15579_Migrate_scenes_to_required_components.md new file mode 100644 index 0000000000..10bfe15129 --- /dev/null +++ b/release-content/0.15/migration-guides/15579_Migrate_scenes_to_required_components.md @@ -0,0 +1,26 @@ +Asset handles for scenes and dynamic scenes must now be wrapped in the `SceneRoot` and `DynamicSceneRoot` components. Raw handles as components no longer spawn scenes. + +Additionally, `SceneBundle` and `DynamicSceneBundle` have been deprecated. Instead, use the scene components directly. + +Previously: + +```rust +let model_scene = asset_server.load(GltfAssetLabel::Scene(0).from_asset("model.gltf")); + +commands.spawn(SceneBundle { + scene: model_scene, + transform: Transform::from_xyz(-4.0, 0.0, -3.0), + ..default() +}); +``` + +Now: + +```rust +let model_scene = asset_server.load(GltfAssetLabel::Scene(0).from_asset("model.gltf")); + +commands.spawn(( + SceneRoot(model_scene), + Transform::from_xyz(-4.0, 0.0, -3.0), +)); +``` diff --git a/release-content/0.15/migration-guides/15582_Synchronize_removed_components_with_the_render_world.md b/release-content/0.15/migration-guides/15582_Synchronize_removed_components_with_the_render_world.md new file mode 100644 index 0000000000..4b9270614f --- /dev/null +++ b/release-content/0.15/migration-guides/15582_Synchronize_removed_components_with_the_render_world.md @@ -0,0 +1 @@ +The retained render world notes should be updated to explain this edge case and `SyncComponentPlugin` diff --git a/release-content/0.15/migration-guides/15583_Rename_BreakLineOn_to_LineBreak.md b/release-content/0.15/migration-guides/15583_Rename_BreakLineOn_to_LineBreak.md new file mode 100644 index 0000000000..ba45c65c27 --- /dev/null +++ b/release-content/0.15/migration-guides/15583_Rename_BreakLineOn_to_LineBreak.md @@ -0,0 +1 @@ +`BreakLineOn` was renamed to `LineBreak`, and parameters named `linebreak_behavior` were renamed to `linebreak`. diff --git a/release-content/0.15/migration-guides/15585_move_ANDROID_APP_to_bevy_window.md b/release-content/0.15/migration-guides/15585_move_ANDROID_APP_to_bevy_window.md new file mode 100644 index 0000000000..c80eee104d --- /dev/null +++ b/release-content/0.15/migration-guides/15585_move_ANDROID_APP_to_bevy_window.md @@ -0,0 +1 @@ +If you use the `android_activity` reexport from `bevy::winit::android_activity`, it is now in `bevy::window::android_activity`. Same for the `ANDROID_APP` static diff --git a/release-content/0.15/migration-guides/15586_Featuregate_all_image_formats.md b/release-content/0.15/migration-guides/15586_Featuregate_all_image_formats.md new file mode 100644 index 0000000000..a11b9a8436 --- /dev/null +++ b/release-content/0.15/migration-guides/15586_Featuregate_all_image_formats.md @@ -0,0 +1,14 @@ +Image formats that previously weren’t feature-gated are now feature-gated, meaning they will have to be enabled if you use them: + +- `avif` +- `ff` (Farbfeld) +- `gif` +- `ico` +- `tiff` + +Additionally, the `qoi` feature has been added to support loading QOI format images. + +Previously, these formats appeared in the enum by default, but weren’t actually enabled via the `image` crate, potentially resulting in weird bugs. Now, you should be able to add these features to your projects to support them properly. +--- + +If you were individually configuring the `bevy_render` crate, the feature flags for the general image formats were moved to `bevy_image` instead. For example, `bevy_render/png` no longer exists, and `bevy_image/png` is the new location for this. The texture formats are still available on `bevy_render`, e.g. `bevy_render/ktx2` is needed to fully enable `ktx2` support, and this will automatically enable `bevy_image/ktx2` for loading the textures. diff --git a/release-content/0.15/migration-guides/15589_Impose_a_more_sensible_ordering_for_animation_graph_evalua.md b/release-content/0.15/migration-guides/15589_Impose_a_more_sensible_ordering_for_animation_graph_evalua.md new file mode 100644 index 0000000000..1027a6c626 --- /dev/null +++ b/release-content/0.15/migration-guides/15589_Impose_a_more_sensible_ordering_for_animation_graph_evalua.md @@ -0,0 +1,7 @@ +> +This section is optional. If there are no breaking changes, you can delete this section. + + +- If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes +- Simply adding new functionality is not a breaking change. +- Fixing behavior that was definitely a bug, rather than a questionable design choice is not a breaking change. diff --git a/release-content/0.15/migration-guides/15591_Text_rework.md b/release-content/0.15/migration-guides/15591_Text_rework.md new file mode 100644 index 0000000000..1995cf7cdd --- /dev/null +++ b/release-content/0.15/migration-guides/15591_Text_rework.md @@ -0,0 +1,31 @@ +TODO: very breaking + +__Accessing text spans by index__ + +Text sections are now text sections on different entities in a hierarchy, Use the new `TextReader` and `TextWriter` system parameters to access spans by index. + +Before: + +```rust +fn refresh_text(mut query: Query<&mut Text, With>, time: Res
- @alice-i-cecile + github + email
Secretary
@@ -80,7 +83,8 @@

Leadership

François Mockers
- @mockersf + github + email
@@ -91,7 +95,8 @@

Leadership

Robert Swain - @superdump + github + email @@ -102,7 +107,8 @@

Leadership

James Liu - @james7132 + github + email @@ -114,7 +120,7 @@

Leadership

Transparency

-Bevy Foundation is a Washington state non-profit (with a pending 501(c)(3) application). We strive to make our operations transparent: +Bevy Foundation is a 501(c)(3) public charity, incorporated as a Washington state non-profit. We strive to make our operations transparent:

    diff --git a/templates/layouts/base.html b/templates/layouts/base.html index 190bba0c60..4b0b63806f 100644 --- a/templates/layouts/base.html +++ b/templates/layouts/base.html @@ -10,7 +10,7 @@ {% if section_or_page %} {# Possible docs root section paths. A temporary workaround. TODO: issue #1181(https://github.com/bevyengine/bevy-website/issues/1181) find a better solution #} - {% set_global root_section_paths = ["learn/quick-start", "learn/book", "learn/migration-guides", "learn/advanced-examples", "learn/errors", "contributing"] %} + {% set_global root_section_paths = ["learn/quick-start", "learn/book", "learn/migration-guides", "learn/advanced-examples", "learn/errors", "learn/contribute"] %} {% for root_section_path in root_section_paths %} {% set components = root_section_path | split(pat="/") %} {% if section_or_page.components | slice(end=components | length) == components %} @@ -63,12 +63,12 @@ {% set show_nav_toggle = true %} {% elif section.path is starting_with("/assets/") %} {% set show_nav_toggle = true %} - {% elif section.path is starting_with("/contributing/") %} + {% elif section.path is starting_with("/contribute/") %} {% set show_nav_toggle = true %} {% endif %} {% elif page %} {% if page.path is starting_with("/learn/book/") or page.path is starting_with("/learn/migration-guides/") or page.path is starting_with("/learn/errors/") or page.path - is starting_with("/assets/") or page.path is starting_with("/contributing/") %} + is starting_with("/assets/") or page.path is starting_with("/contribute/") %} {% set show_nav_toggle = true %} {% endif %} {% endif %} diff --git a/templates/macros/base.html b/templates/macros/base.html index 56268a391f..827ac180bc 100644 --- a/templates/macros/base.html +++ b/templates/macros/base.html @@ -12,8 +12,8 @@ Quick Start {% elif section_or_page.path is starting_with("/learn/advanced-examples") %} Advanced Examples - {% elif section_or_page.path is starting_with("/contributing/") %} - Contributing Guide + {% elif section_or_page.path is starting_with("/contribute/") %} + Contribute {% elif section_or_page.path is starting_with("/news/") %} News {% elif section_or_page.path == "/" %} diff --git a/templates/news-page.html b/templates/news-page.html index 568a6fa886..a5e47be23f 100644 --- a/templates/news-page.html +++ b/templates/news-page.html @@ -7,7 +7,7 @@ {% block page_content %}

    {{ page.title }}

    - Posted on {{ page.date | date(format="%B %d, %Y") }} by {% if page.authors %}{% for author in page.authors %}{{ author }}{% endfor %}{% else %}Bevy Contributors{% endif %} + Posted on {{ page.date | date(format="%B %-d, %Y") }} by {% if page.authors %}{% for author in page.authors %}{{ author }}{% endfor %}{% else %}Bevy Contributors{% endif %} {% if page.extra.twitter or page.extra.github %} ( diff --git a/templates/shortcodes/changelog.md b/templates/shortcodes/changelog.md index 0b6c8a5645..979f1d9318 100644 --- a/templates/shortcodes/changelog.md +++ b/templates/shortcodes/changelog.md @@ -17,7 +17,7 @@ For a complete list of changes, check out the PRs listed below. {% endfor %} diff --git a/templates/shortcodes/contributors.md b/templates/shortcodes/contributors.md index 19a0f751d5..099ff14bc6 100644 --- a/templates/shortcodes/contributors.md +++ b/templates/shortcodes/contributors.md @@ -5,7 +5,7 @@ A huge thanks to the {{ data.contributors | length }} contributors that made this release (and associated docs) possible! In random order: -
      +
        {% for contributor in data.contributors %}
      • {{ contributor.name }}
        • {% endfor %} diff --git a/templates/shortcodes/migration_guides.md b/templates/shortcodes/migration_guides.md index e87fcacad5..a26d6659aa 100644 --- a/templates/shortcodes/migration_guides.md +++ b/templates/shortcodes/migration_guides.md @@ -2,6 +2,7 @@ {% set base_path = macros::release_path(version=version, path="/migration-guides/") %} {% set guides_data = load_data(path=macros::path_join(path_a=base_path, path_b="/_guides.toml")) %} +{% set previous_area = "" %}
      {{ guide_body }} diff --git a/templates/shortcodes/release_notes.md b/templates/shortcodes/release_notes.md index f9d03148b8..31db714c56 100644 --- a/templates/shortcodes/release_notes.md +++ b/templates/shortcodes/release_notes.md @@ -9,7 +9,9 @@
      • Authors: {{ release_note.authors | join(sep=", ")}}
        • -
      • Pull Request
        • + {% for pr in release_note.prs %} +
      • PR #{{ pr }}
        • + {% endfor %}
      {{ release_note_body | replace(from='POST_PATH', to=page.colocated_path) | markdown }} diff --git a/templates/sponsors.html b/templates/sponsors.html index c5c9dfda4c..67e011d738 100644 --- a/templates/sponsors.html +++ b/templates/sponsors.html @@ -35,8 +35,8 @@ {% if donor.past %} {% continue %} {% endif %} - - + {# Note: this "donor filtering logic" _must_ be kept in sync with the logic in donate.html #} + {# If we can find a way to reuse this logic in Zola, we absolutely should! #} {% if donor.amount >= tier.amount %} {% if next_tier and donor.amount >= next_tier.amount %} {% continue %} @@ -73,6 +73,8 @@

      ${{ tier.amount }} / month

      src="/assets/donor_logos/{{ donor.logo }}" {% if donor.name %} alt="{{ donor.name }} logo" + {% else %} + alt="{{ donor.logo | split(pat=".") | first }} logo" {% endif %} />