Merge remote-tracking branch 'origin/main' into pcss

.cargo/config_fast_builds.toml

@@ -134,9 +134,10 @@ rustflags = [
 # rustup component add llvm-tools
 # ```
 linker = "rust-lld.exe"
+rustdocflags = ["-Clinker=rust-lld.exe"]
 rustflags = [
   # Nightly
-  # "-Zshare-generics=y",
+  # "-Zshare-generics=n", # This needs to be off if you use dynamic linking on Windows.
   # "-Zthreads=0",
 ]
 
@@ -145,7 +146,7 @@ rustflags = [
 # [profile.dev]
 # debug = 1
 
-# This is enables you to run the CI tool using `cargo ci`.
+# This enables you to run the CI tool using `cargo ci`.
 # This is not enabled by default, you need to copy this file to `config.toml`.
 [alias]
 ci = "run --package ci --"

.github/contributing/engine_style_guide.md

@@ -14,7 +14,7 @@ For more advice on contributing to the engine, see the [relevant section](../../
    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`.
+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
 

.github/linters/.markdown-lint.yml

@@ -1,3 +1,9 @@
 {
-    "MD013": false
+    "MD013": false,
+    "no-inline-html": {
+        "allowed_elements": [
+            "details",
+            "summary"
+        ]
+    }
 }

.github/pull_request_template.md

@@ -16,14 +16,26 @@
 
 ---
 
-## Changelog
+## Showcase
 
-> This section is optional. If this was a trivial fix, or has no externally-visible impact, you can delete this section.
+> This section is optional. If this PR does not include a visual change or does not add a new feature, you can delete this section.
 
-- What changed as a result of this PR?
-- If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings
-- Stick to one or two sentences. If more detail is needed for a particular change, consider adding it to the "Solution" section
-  - If you can't summarize the work, your change may be unreasonably large / unrelated. Consider splitting your PR to make it easier to review and merge!
+- Help others understand the result of this PR by showcasing your awesome work!
+- If this PR adds a new feature or public API, consider adding a brief pseudo-code snippet of it in action
+- If this PR includes a visual change, consider adding a screenshot, GIF, or video
+  - If you want, you could even include a before/after comparison!
+- If the Migration Guide adequately covers the changes, you can delete this section
+
+While a showcase should aim to be brief and digestible, you can use a toggleable section to save space on longer showcases:
+
+<details>
+  <summary>Click to view showcase</summary>
+
+```rust
+println!("My super cool code.");
+```
+
+</details>
 
 ## Migration Guide
 

.github/workflows/ci.yml

@@ -6,6 +6,7 @@ on:
   push:
     branches:
       - main
+      - release-*
 
 env:
   CARGO_TERM_COLOR: always
@@ -218,7 +219,7 @@ jobs:
     steps:
       - uses: actions/checkout@v4
       - name: Check for typos
-        uses: crate-ci/typos@v1.21.0
+        uses: crate-ci/typos@v1.23.1
       - name: Typos info
         if: failure()
         run: |

.github/workflows/post-release.yml

@@ -27,9 +27,9 @@ jobs:
           # Read the current version from Cargo.toml
           current_version=$(cargo metadata --format-version 1 --no-deps | \
             jq --raw-output '.packages | .[] | select(.name == "bevy").version')
-          # Sanity check: current version should be 0.X.Y
-          if ! grep -q '^0\.[0-9]\+\.[0-9]\+$' <<< "${current_version}"; then
-            echo "Invalid version (not in 0.X.Y format): ${current_version}"
+          # Sanity check: current version should be 0.X.Y-dev
+          if ! grep -q '^0\.[0-9]\+\.[0-9]\+-dev$' <<< "${current_version}"; then
+            echo "Invalid version (not in 0.X.Y-dev format): ${current_version}"
             exit 1
           fi
           minor_version=$(sed 's/^0\.\([0-9]\+\).*/\1/' <<< "${current_version}")

.github/workflows/validation-jobs.yml

@@ -6,6 +6,7 @@ on:
   push:
     branches:
       - main
+      - release-*
 
 concurrency:
   group: ${{github.workflow}}-${{github.ref}}

CONTRIBUTING.md

@@ -258,8 +258,8 @@ Once that's ready, get a sign-off on the broad vision and goals from the appropr
 This is the primary review step: maintainers and SMEs should be broadly patient and supportive even if they're skeptical until a proper design doc is in hand to evaluate.
 
 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 `S-Controversial`, but with a sign-off-in-priniciple, things should go more smoothly.
+Post PRs that you need reviews on in your group's forum thread, ask for advice, and share the load.
+Controversial PRs are still `S-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!