diff --git a/.github/workflows/check_urls.yml b/.github/workflows/check_urls.yml index 7d0c968a945..26ece3c4746 100644 --- a/.github/workflows/check_urls.yml +++ b/.github/workflows/check_urls.yml @@ -1,12 +1,10 @@ name: 🌐 Check URLs on: - push: - pull_request: schedule: - # Every day at 18:00 UTC. + # Every Friday at 16:27 UTC. # URLs can decay over time. Setting up a schedule makes it possible to be warned # about dead links as soon as possible. - - cron: "0 18 * * *" + - cron: "27 16 * * FRI" jobs: check-urls: diff --git a/.lycheeignore b/.lycheeignore index 12889792f87..3c5eca4a6c1 100644 --- a/.lycheeignore +++ b/.lycheeignore @@ -12,6 +12,8 @@ tcp:\/\/.* .*asecuritysite\.com.* .*intel\.com.* .*reddit\.com.* +.*inkscape.org.* +.*computerhope.com* # Don't check URLs from these websites due to frequent rate limits (error 429) or timeouts. .*adobe\.com.* diff --git a/about/release_policy.rst b/about/release_policy.rst index 81a390200de..86961df9892 100644 --- a/about/release_policy.rst +++ b/about/release_policy.rst @@ -209,9 +209,9 @@ When is the next release out? While Godot contributors aren't working under any deadlines, we strive to publish minor releases relatively frequently. -In particular, after the very length release cycle for 4.0, we are pivoting to -a faster paced development workflow, 4.1 released 4 months after 4.0, and 4.2 -released 4 months after 4.1 +In particular, after the very long release cycle for 4.0, we are pivoting to +a faster-paced development workflow, 4.1 released 4 months after 4.0, and 4.2 +released 4 months after 4.1. Frequent minor releases will enable us to ship new features faster (possibly as experimental), get user feedback quickly, and iterate to improve those diff --git a/community/tutorials.rst b/community/tutorials.rst index 934ce4e632f..fd989fc1b27 100644 --- a/community/tutorials.rst +++ b/community/tutorials.rst @@ -33,6 +33,7 @@ Text tutorials - `GDScript website by Andrew Wilkes `__ - `Godot Recipes by KidsCanCode `__ - `Godot Tutorials by SomethingLikeGames `__ +- `GameDev Academy by Zenva `__ - `Game Dev Artisan website `__ - `Night Quest Games Blog `__ diff --git a/contributing/development/configuring_an_ide/visual_studio.rst b/contributing/development/configuring_an_ide/visual_studio.rst index 25bfdbdd03c..4c26160edc5 100644 --- a/contributing/development/configuring_an_ide/visual_studio.rst +++ b/contributing/development/configuring_an_ide/visual_studio.rst @@ -8,6 +8,12 @@ by `Microsoft `_ that's free for individual use or non-co It has many useful features, such as memory view, performance view, source control and more. +.. note:: + + This documentation is for contributions to the game engine, and not using + Visual Studio as a C# editor. To code C# in an external editor, see + :ref:`the C# guide to configure an external editor `. + Importing the project --------------------- diff --git a/contributing/development/configuring_an_ide/visual_studio_code.rst b/contributing/development/configuring_an_ide/visual_studio_code.rst index 7874cdc2641..e74dfbed9c4 100644 --- a/contributing/development/configuring_an_ide/visual_studio_code.rst +++ b/contributing/development/configuring_an_ide/visual_studio_code.rst @@ -3,6 +3,12 @@ Visual Studio Code ================== +.. note:: + + This documentation is for contributions to the game engine, and not using + Visual Studio Code as a C# or GDScript editor. To code C# or GDScript in an external editor, see + :ref:`the C# guide to configure an external editor `. + `Visual Studio Code `_ is a free cross-platform code editor by `Microsoft `_ (not to be confused with :ref:`doc_configuring_an_ide_vs`). diff --git a/contributing/development/core_and_modules/internal_rendering_architecture.rst b/contributing/development/core_and_modules/internal_rendering_architecture.rst index 0ab0a1bbbba..1c2310ab2ca 100644 --- a/contributing/development/core_and_modules/internal_rendering_architecture.rst +++ b/contributing/development/core_and_modules/internal_rendering_architecture.rst @@ -426,13 +426,7 @@ release. 2D light rendering is performed in a single pass to allow for better performance with large amounts of lights. -.. UPDATE: Planned feature. When Forward+ and Mobile feature 2D batching, -.. update this. - -The Forward+ and Mobile rendering methods don't feature 2D batching yet, but -it's planned for a future release. - -The Compatibility renderer features 2D batching to improve performance, which is +All rendering methods feature 2D batching to improve performance, which is especially noticeable with lots of text on screen. MSAA can be enabled in 2D to provide "automatic" line and polygon antialiasing, @@ -456,9 +450,10 @@ used to calculate particle collisions in 2D. Batching and instancing ~~~~~~~~~~~~~~~~~~~~~~~ -In the Forward+ renderer, Vulkan instancing is used to group rendering -of identical objects for performance. This is not as fast as static mesh -merging, but it still allows instances to be culled individually. +In the Forward+ renderer, Vulkan instancing is used to group rendering of +identical opaque or alpha-tested objects for performance. (Alpha-blended objects +are never instanced.) This is not as fast as static mesh merging, but it still +allows instances to be culled individually. Light, decal and reflection probe rendering ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/contributing/development/core_and_modules/unit_testing.rst b/contributing/development/core_and_modules/unit_testing.rst index e9d94db7bd0..1b298a54b6b 100644 --- a/contributing/development/core_and_modules/unit_testing.rst +++ b/contributing/development/core_and_modules/unit_testing.rst @@ -4,7 +4,7 @@ Unit testing ============ Godot Engine allows to write unit tests directly in C++. The engine integrates -the `doctest `_ unit testing framework which +the `doctest `_ unit testing framework which gives ability to write test suites and test cases next to production code, but since the tests in Godot go through a different ``main`` entry point, the tests reside in a dedicated ``tests/`` directory instead, which is located at the root @@ -208,7 +208,7 @@ for more complex ones if you think that it deserves a better explanation. .. seealso:: - `doctest: Assertion macros `_. + `doctest: Assertion macros `_. Logging ~~~~~~~ @@ -236,7 +236,7 @@ output can be redirected to an XML file: .. seealso:: - `doctest: Logging macros `_. + `doctest: Logging macros `_. Testing failure paths ~~~~~~~~~~~~~~~~~~~~~ diff --git a/contributing/development/editor/creating_icons.rst b/contributing/development/editor/creating_icons.rst index cdb6047311d..2626e0afbf3 100644 --- a/contributing/development/editor/creating_icons.rst +++ b/contributing/development/editor/creating_icons.rst @@ -38,7 +38,7 @@ Color conversion for light editor themes If the user has configured their editor to use a light theme, Godot will convert the icon's colors based on a -`set of predefined color mappings `__. +`set of predefined color mappings `__. This is to ensure the icon always displays with a sufficient contrast rate. Try to restrict your icon's color palette to colors found in the list above. Otherwise, your icon may become difficult to read on a light background. diff --git a/contributing/documentation/docs_contribution_checklist.rst b/contributing/documentation/docs_contribution_checklist.rst new file mode 100644 index 00000000000..ed7186a5374 --- /dev/null +++ b/contributing/documentation/docs_contribution_checklist.rst @@ -0,0 +1,71 @@ +.. _docs_contribution_checklist: + +Documentation contribution checklist +==================================== + +This page is a summary of the guidelines to follow when contributing to the +documentation. Before you press that **Create pull request** button on GitHub, +read over this list to double check if you missed anything. + +You don't need to read all the guidelines here in order to start contributing. +If you do miss something, it will be pointed out during review. However, +following the guidelines you are aware of as best you can will help speed up the +review process. + +Writing style +------------- + +:ref:`See here. ` + +- Use the active voice. +- Use precise action verbs. +- Avoid verbs that end in -ing. +- Remove unnecessary adverbs and adjectives. +- Ban these 8 words: obvious, simple, basic, easy, actual, just, clear, and however. +- Use explicit references. +- Use 's to show possession. +- Use the Oxford comma. + +Code examples +------------- + +- Use dynamic typing. :ref:`See here. ` +- Use real, practical examples. Avoid ``foo`` / ``bar`` examples. :ref:`See here. ` + +Manual style and formatting +--------------------------- + +- Use common vocabulary for the editor interface. :ref:`See here. ` +- Use ``:kbd:`` for keyboard shortcuts. :ref:`See here. ` +- Literals use ``code style``. :ref:`See here. ` +- Classes link to the class reference once, then use ``ClassName`` for the rest + of the page. + Methods and properties link to the class ref once, then use ``PropertyName`` + for the rest of the page. :ref:`See here. ` +- Editor UI, like menus, windows, and editor navigation paths, use + ``Bold Style``. :ref:`See here. ` +- Link to project settings when referencing them. :ref:`See here. ` +- Text is manually wrapped to 80-100 characters. :ref:`See here. ` +- No trailing whitespace at the end of lines. +- Most of the time, avoid mentioning a specific Godot version. :ref:`See here. ` + +Images and videos +----------------- + +- New (and updated) images are in WebP format. :ref:`See here. ` +- Editor screenshots are cropped. :ref:`See here. ` +- Images larger than 1080p or 300kb are scaled down. :ref:`See here. ` +- Outlines in images use ``fffb44`` yellow. :ref:`See here. ` +- Videos use the ``:autoplay:``, ``:loop:``, and ``:muted:`` tags. :ref:`See here. ` + +GitHub +------ + +- The PR title starts with a word like ``Fix``, ``Add``, ``Update``, + ``Clarify``, or ``Improve``. +- If the PR closes an issue, link to the issue with one of GitHub's + `keywords `__: + ``closes``, ``fixes``, or ``resolves``, in the text of the PR. +- Ideally, PR contains a single commit. However, multiple commits can be + :ref:`squashed ` later. + diff --git a/contributing/documentation/docs_image_guidelines.rst b/contributing/documentation/docs_image_guidelines.rst index b2537d32869..05f30dd8592 100644 --- a/contributing/documentation/docs_image_guidelines.rst +++ b/contributing/documentation/docs_image_guidelines.rst @@ -36,6 +36,8 @@ dramatically increases file size. If you're taking screenshots on a higher resolution screen the screenshot should be scaled down. There are instructions on how to do this later on this page. +.. _doc_docs_image_guidelines_format_conversion: + Format conversion ~~~~~~~~~~~~~~~~~ @@ -59,6 +61,8 @@ it may have the ability to open an image then save it as a WebP file. GIFs should be avoided. Their compression is inefficient and they only support a 256-color palette with 1-bit transparency. +.. _doc_docs_image_guidelines_cropping: + Cropping ~~~~~~~~ @@ -94,6 +98,8 @@ If you make a mistake and overcrop don't worry, cropping is non-destructive in Krita and can be adjusted. Click on the image with your cropping tool still selected and the controls will return. +.. _doc_docs_image_guidelines_scaling_down: + Scaling down an image ~~~~~~~~~~~~~~~~~~~~~ @@ -119,6 +125,8 @@ If it's still over 300KB change to lossy compression and slowly increase the com 300KB. If this results in noticeable compression artifacts using less compression is fine, even if the file size is bigger. +.. _doc_docs_image_guidelines_outlines: + Outlines, arrows and text ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -160,6 +168,8 @@ Where ``documentation_image.webp`` would be changed to the name of the image you created. Name your images in a way that makes their meaning clear, possibly with a prefix that makes their relationship to a documentation page explicit. +.. _doc_docs_image_guidelines_videos: + Videos ------ diff --git a/contributing/documentation/docs_writing_guidelines.rst b/contributing/documentation/docs_writing_guidelines.rst index 88552f4196e..e22829b90b8 100644 --- a/contributing/documentation/docs_writing_guidelines.rst +++ b/contributing/documentation/docs_writing_guidelines.rst @@ -37,6 +37,8 @@ There are 3 rules to describe classes: See the :ref:`content guidelines ` for information on the types of documentation you can write in the official documentation. +.. _doc_docs_writing_guidelines_clear_english_rules: + 7 rules for clear English ------------------------- @@ -283,6 +285,8 @@ element of a list with more than two elements. How to write methods and classes -------------------------------- +.. _doc_docs_writing_guidelines_dynamic_typing: + Dynamic vs static typing ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -335,6 +339,8 @@ The exception is topics that explain static typing concepts to users. var choice = randi() % size return arguments[choice] +.. _doc_docs_writing_guidelines_real_world_code_example: + Use real-world code examples where appropriate ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -452,6 +458,7 @@ documentation and in Godot, it will display like ``this``. When you edit XML files in the Godot repository, replace existing arguments written like 'this' or \`this\` with ``[code]this[/code]``. +.. _doc_docs_writing_guidelines_common_vocabulary: Common vocabulary to use in Godot's documentation ------------------------------------------------- @@ -487,6 +494,8 @@ class names, which you can't fold, are ``Classes`` e.g. the ``properties``. E.g. ``position`` or ``modulate color`` are both ``properties``. +.. _doc_docs_writing_guidelines_keyboard_shortcuts: + Keyboard shortcut guidelines ---------------------------- @@ -507,6 +516,7 @@ examples with the ``:kbd:`` tag left as-is for better visibility: - Press ``:kbd:`Space``` and hold the left mouse button to pan in the 2D editor. - Press ``:kbd:`Shift + Up Arrow``` to move the node upwards by 8 pixels. +.. _doc_docs_writing_guidelines_manual_style: Manual style guidelines ----------------------- @@ -567,6 +577,8 @@ is fine too. - Godot uses *nodes* with *scripts* in a *scene tree*. - Godot uses **nodes** with **scripts** in a **scene tree**. +.. _doc_docs_writing_guidelines_literals: + Literals ~~~~~~~~ @@ -576,6 +588,8 @@ Use ``code style`` for literal values. Literals include: - Float literals like ``0.0``, ``0.5``, ``-2.0``, or ``100.0`` - Vector literals like ``(0.0, 0.0)``, ``(0.5, -0.5, 0.5)``, or ``(1.0, 2.0, 3.0, 4.0)``. +.. _doc_docs_writing_guidelines_class_properties_methods: + Classes, properties, and methods ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -591,6 +605,8 @@ link. When discussing properties in the context of the inspector, use **bold style** instead. +.. _doc_docs_writing_guidelines_editor_ui: + Editor UI ~~~~~~~~~ @@ -613,6 +629,8 @@ reader must navigate. Use ``>`` as a separator. You can omit ellipses in menu na .. note:: Sometimes, ``->`` or ``→`` is used as a separator. This is nonstandard. Replace it with ``>`` if you are already making changes to a section. +.. _doc_docs_writing_guidelines_project_settings: + Project settings ~~~~~~~~~~~~~~~~ @@ -625,6 +643,8 @@ rendered, prefer splitting the setting name and the section when the link is lon - In the project settings under **Application > Run**, set :ref:`Max FPS` to ``60``. - In **Project Settings > Application > Run**, set :ref:`Max FPS` to ``60``. +.. _doc_docs_writing_guidelines_manually_wrapping_lines: + Manually wrapping lines ~~~~~~~~~~~~~~~~~~~~~~~ @@ -710,6 +730,8 @@ See the `Sphinx documentation `__ for more information. +.. _doc_docs_writing_guidelines_specific_version: + When to refer to a specific Godot version ----------------------------------------- diff --git a/contributing/documentation/index.rst b/contributing/documentation/index.rst index 68d8697ff62..54e23de3859 100644 --- a/contributing/documentation/index.rst +++ b/contributing/documentation/index.rst @@ -25,6 +25,7 @@ documentation. content_guidelines docs_writing_guidelines docs_image_guidelines + docs_contribution_checklist Writing the manual ------------------ diff --git a/contributing/workflow/bug_triage_guidelines.rst b/contributing/workflow/bug_triage_guidelines.rst index 45a40bef4c5..cb868562adc 100644 --- a/contributing/workflow/bug_triage_guidelines.rst +++ b/contributing/workflow/bug_triage_guidelines.rst @@ -12,24 +12,33 @@ hesitate to propose modifications to the following guidelines. Issues management ----------------- -GitHub proposes various features to manage issues: +For issue management, we use the following GitHub processes: -- Set one or several labels from a predefined list -- Set one milestone from a predefined list -- Keep track of the issue in the project dashboard -- Define one contributor as "assignee" among the Godot engine - organization members +- Each issue and pull request (PR) is categorized with a set of *labels*, + sometimes called "tags". +- Each PR is assigned to a *milestone*. Some issues can also be assigned to a + *milestone* (see below). +- Issues can have an *assignee*, who is a contributor among Godot maintainers. +- Issues can be put in one or more *projects*. +- PRs can be *linked* to one or more issues which they "fix" or "close". -As the Godot engine organization on GitHub currently has a restricted -number of contributors, we do not use assignees extensively for now. All -contributors are welcome to take on any issue, if relevant after mentioning -it on the issue ticket and/or discussing the best way to resolve it with -other developers. +We don't yet extensively use or rely on some other GitHub processes: -For the time being, we do not use the project dashboard feature either. +- Issue close reasons (completed, not planned, duplicate). While we use these, + it is not consistent, and older issues are all closed as "completed", so the + issue close reason should not be relied on. +- Issue *types* (Bug, Feature, Task). +- Issue *relationships*. -As far as possible, we try to assign labels (and milestones, when relevant) -to both issues and pull requests. +We only use the assignees feature for Godot maintainers who are members of the +Godot Engine GitHub organization, and even then not in all cases. For other +issues, we track who is working on an issue by comments on the issue and linked +pull requests. Most issues are available for any contributor to take on, after +discussing it with other contributors. If you would like to work on an issue, +first check that no one else is working on it, by looking for a linked pull +request, a comment "claiming" the issue, or an assignee. If no one else is +working on the issue, leave a comment on the issue to "claim" it and start +working on it. Labels ~~~~~~ @@ -37,10 +46,20 @@ Labels The following `labels `__ are currently defined in the Godot repository: -**Categories:** +Categories: +^^^^^^^^^^^ -- *Archived*: either a duplicate of another issue, or invalid. Such an - issue would also be closed. +- *Archived*: used to filter issues closed with a resolution other than "fixed". + + - For issues, added to all issues that are not resolved by engine or + documentation changes. This includes duplicate issues, user error, or + reports in the wrong repository. + Since we don't rely on GitHub's issue close reasons (``completed``, ``not + planned``, and ``duplicate``), it is possible for an issue to be closed as + ``completed`` with the *Archived* label. + - For PRs, added to all closed PRs that are not merged. This includes superseded + or duplicate PRs, Git or GitHub mistakes, and valid PRs that end up not merged. + - *Breaks compat*: describes something that can only be fixed by breaking compatibility with existing projects. - *Bug*: describes something that is not working properly. @@ -66,12 +85,11 @@ currently defined in the Godot repository: should be filed on the `godot-docs `_ repository. - *Enhancement*: describes a proposed enhancement to an existing functionality. -- *Feature proposal*: describes a wish for a new feature to be - implemented. Note that the main Godot repository no longer accepts - feature requests. Please use - `godot-proposals `__ instead. - PRs which add new features but do not have a corresponding proposal use this - label. +- *Feature proposal*: used for PRs adding new features which do not have a + corresponding proposal use this label. The label is removed when a feature + proposal is created and linked. The main Godot repository no longer accepts + feature requests as issues. Please use the `godot-proposals + `__ repository instead. - *For PR meeting*: the issue needs to be discussed in a pull request meeting. These meetings are public and are held on the `Godot Contributors Chat `_. - *Good first issue*: the issue is *assumed* to be an easy one to fix, which makes @@ -89,29 +107,33 @@ currently defined in the Godot repository: - *Performance*: issues that directly impact engine or editor performance. Can also be used for pull requests that improve performance or add low-end-friendly options. Should not be coupled with *Usability*. -- *Production*: Relates to the production team. - *Regression*: the bug appeared after a stable release not exhibiting the bug was released. - *Salvageable*: the pull request can't be merged due to design issues or merge conflicts and its author is not active anymore. However, it can still - be picked up by an external contributor to bring it to a mergeable state. + be picked up by another contributor to bring it to a mergeable state. To do so, you need to open a new pull request based on the original pull request. +- *Spam*: intentional spam issues, and extremely low-effort PRs. Used + sparingly, since we give contributors and users the benefit of the doubt. In + most cases, *Needs work* or *Archived* is more appropriate. - *Tracker*: issue used to track other issues (like all issues related to the plugin system). - *Usability*: issues that directly impact user usability. Should not be coupled with *Performance*. -The categories are used for general triage of the issues. They can be -combined in some way when relevant, e.g. an issue can be labelled -*Enhancement* and *Usability* at the same time if it's an issue to improve -usability. Or *Feature proposal* and *Discussion* if it's a non-consensual -feature request, or one that is not precise enough to be worked on. -At least one of the categories *Bug*, *Enhancement* or *Discussion* is used to -describe an issue or pull request. +The categories are used for general triage of the issues. They can be combined +in some way when relevant, e.g. an issue can be labeled *Bug* and *Usability* +at the same time if it's a bug that affects usability. Or *Enhancement* and +*Discussion* if it's an improvement that requires discussion of the best +approach. At least one of the categories *Bug*, *Enhancement*, or *Discussion* +are used to describe an issue or pull request. -**Topics:** +Topics: +^^^^^^^ -- *2D*: relates to 2D-specific issues. Should be coupled with one of the labels below, and should not be coupled with *3D*. -- *3D*: relates to 3D-specific issues. Should be coupled with one of the labels below, and should not be coupled with *2D*. +- *2D*: relates to 2D nodes. Should be coupled with one of the labels + below, and should not be coupled with *3D*. +- *3D*: relates to 3D nodes. Should be coupled with one of the labels + below, and should not be coupled with *2D*. - *Animation*: relates to the Animation system, editors and importers. - *Assetlib*: relates to issues with the asset library. - *Audio*: relates to the audio features (low- and high-level). @@ -119,7 +141,7 @@ describe an issue or pull request. buildsystem or to compiler peculiarities. - *Codestyle*: relates to the programming style used within the codebase. - *Core*: anything related to the core engine. Specific topics are split off separately as they crop up. -- *Dotnet*: relates to the C# / Dotnet bindings. +- *Dotnet*: relates to the C# / .NET bindings. - *Editor*: relates to issues in the editor (mainly UI). - *Export*: relates to the export system and templates. - *GDExtension*: relates to the GDExtension system for native extensions. @@ -146,9 +168,10 @@ unthinkable to see issues that fit two bills. The general idea is that there will be specialized contributors teams behind all topics, so they can focus on the issues labelled with their team's topic. -**Platforms:** +Platforms: +^^^^^^^^^^ -*Android*, *iOS*, *Linux*, *macOS*, *Web*, *Windows* +*Android*, *iOS*, *LinuxBSD*, *macOS*, *Web*, *Windows* By default, it is assumed that a given issue applies to all platforms. If one of the platform labels is used, it is then exclusive and the @@ -176,6 +199,12 @@ use the following `labels `__: it a great fit for new contributors who want to become familiar with the code base. It should be removed while an active PR is available, that resolves this issue. +- *Linked demo PR*: the PR has a corresponding PR to the + `Godot Demo Projects `__ + repository which must be merged at the same time. Any changes to code in + tutorials that have a corresponding demo, such as :ref:`doc_your_first_2d_game`, + need to update both repositories so that the tutorial code stays in sync with + the completed demo. - *Needs work*: the pull request needs additional work before it can be merged. - *Python*: Pull requests that update Python code. - *Salvageable*: the pull request can't be merged due to design issues or @@ -184,8 +213,11 @@ use the following `labels `__: To do so, you need to open a new pull request based on the original pull request. - *Tracker*: issue used to track other issues (like all issues related to the plugin system). +- *Waiting on PR merge*: the PR documents an engine PR that has not been merged + yet. -**Area:** +Area: +^^^^^ - *About*: Issues and PRs related to the About section of the documentation and other general articles. - *Class reference*: the issue is about the class reference, not a documentation page. @@ -194,7 +226,8 @@ use the following `labels `__: - *Getting started*: Issues and PRs related to the Getting Started section of the documentation. - *Manual*: Issues and PRs related to the Manual/Tutorials section of the documentation. -**Content:** +Content: +^^^^^^^^ - *Images*: Issues and PRs involving outdated or incorrect images in articles. - *Example code*: Issues and PRs involving writing or updating code examples. @@ -204,7 +237,8 @@ use the following `labels `__: - *Redirect*: Issues and PRs involving moving content and adding a redirect rule on the backend. - *Website*: Issues related to adding website features and fixing bugs, whether on the front or back-end, -**Topic:** +Topic: +^^^^^^ The available topics describe the same content as the topics in the main repository. @@ -212,15 +246,42 @@ repository. Milestones ~~~~~~~~~~ -`Milestones `_ correspond to -planned future versions of Godot for which there is an existing roadmap. Issues -that fit in the said roadmap should be filed under the corresponding milestone; -if they don't correspond to any current roadmap, they should be left without -milestone. As a rule of thumb, an issue corresponds to a given milestone if it -concerns a feature that is new in the milestone, or a critical bug that can't be -accepted in any future stable release, or anything that Juan wants to work on -right now. :) - -Contributors are free to pick issues regardless of their assigned milestone; -if a fix is proposed for a bug that was not deemed urgent and thus without -milestone, it would likely still be very welcome. +`Milestones `_ are used for +some issues and all PRs. + +We have milestones for specific minor engine versions, like ``4.5`` and ``4.6``, +as well as general milestones for major engine versions, like ``3.x`` and +``4.x``. In the ``godot-proposals`` repo, we also have a ``5.0`` milestone for +compatibility-breaking changes that will be considered for Godot 5.0, in many +years. + +Issues are assigned to the current development milestone, such as ``4.5``, if +they are related to features introduced in that engine version, or are bugs +(regressions) in that version. Additionally, all issues completed during the +development of that engine version are added to the milestone, so that users can +see at a glance in which minor version an issue was first fixed. We don't always +use the ``4.x`` milestone for issues, since by default all issues are related to +Godot 4.x. However, we do use the ``3.x`` milestone to mark issues that are +specific to Godot 3.x. + +All pull requests are assigned to a milestone. By default, enhancement and +feature PRs are assigned to the ``4.x`` milestone, and bugs are assigned to the +current development milestone, such as ``4.5``. Towards the end of the minor +version's development, PRs currently in that milestone are reassessed. If +a PR is no longer being considered for that version, it is reassigned to either the +major version milestone (``4.x``), or the next minor version milestone (such as +``4.6``). + +Pull requests in the ``4.x`` milestone are reassigned to the current minor +engine version, such as ``4.5``, when the review process is complete, and the +production team decides that the PR is ready to be merged soon. Note that +this usually requires more than one approving review. + +The milestone assigned to a PR is a goal, not a guarantee. New features and +enhancements are merged when they are ready. While reviewers and maintainers do +their best to review PRs in time for the current version, at some point we reach +the beta, feature freeze, and then release; and existing PRs are reassigned to +the next minor version, or to ``4.x``. As a rule, we assign new features to the +``4.x`` milestone initially to avoid continually reassigning a PR from version +to version. However, a PR being in ``4.x`` does not mean it won't be merged; +it's just the default for new features. \ No newline at end of file diff --git a/getting_started/first_2d_game/04.creating_the_enemy.rst b/getting_started/first_2d_game/04.creating_the_enemy.rst index af11ba167e7..3260477aef2 100644 --- a/getting_started/first_2d_game/04.creating_the_enemy.rst +++ b/getting_started/first_2d_game/04.creating_the_enemy.rst @@ -87,6 +87,7 @@ and randomly choose one of the three animation types: func _ready(): var mob_types = Array($AnimatedSprite2D.sprite_frames.get_animation_names()) $AnimatedSprite2D.animation = mob_types.pick_random() + $AnimatedSprite2D.play() .. code-tab:: csharp @@ -106,6 +107,8 @@ to select one of these animation names at random. Meanwhile, in the C# code, we between ``0`` and ``2`` to select one of these names from the list (array indices start at ``0``). The expression ``GD.Randi() % n`` selects a random integer between ``0`` and ``n-1``. +Finally, we call ``play()`` to start playing the chosen animation. + The last piece is to make the mobs delete themselves when they leave the screen. Connect the ``screen_exited()`` signal of the ``VisibleOnScreenNotifier2D`` node to the ``Mob`` and add this code: diff --git a/getting_started/first_2d_game/06.heads_up_display.rst b/getting_started/first_2d_game/06.heads_up_display.rst index 97775cbcbb4..01369424bf2 100644 --- a/getting_started/first_2d_game/06.heads_up_display.rst +++ b/getting_started/first_2d_game/06.heads_up_display.rst @@ -160,10 +160,6 @@ We also need to process what happens when the player loses. The code below will GetNode