diff --git a/changelog.md b/changelog.md index 108fe1e383..350c39d049 100644 --- a/changelog.md +++ b/changelog.md @@ -32,25 +32,26 @@ v1.0.0 - [2757](https://github.com/RuminantFarmSystems/RuFaS/pull/2757) - [minor change] [NoInputChange] [NoOutputChange] Updates version number in `pyproject.toml`. - [2737](https://github.com/RuminantFarmSystems/RuFaS/pull/2737) - [minor change] [NoInputChange] [NoOutputChange] Update CONTRIBUTING.md file to provide forking guidelines for contributors. - [2690](https://github.com/RuminantFarmSystems/RuFaS/pull/2690) - [minor change] [TaskManager] [NoInputChange] [NoOutputChange] Remove hard-coded name for output folder, use user-defined name instead. -- [2720](https://github.com/RuminantFarmSystems/MASM/pull/2720) - [minor change] [Emissions] [NoInputChange] [NoOutputChange] Adds FGF emissions reset when there's a harvest-kill operation and there's none of that feed left in storage. -- [2772](https://github.com/RuminantFarmSystems/MASM/pull/2772) - [minor change] [SimulationEngine] [NoInputChange] [NoOutputChange] Refactors `SimulationEngine`.`_daily_simulation()` to accommodate isolating modules. -- [2791](https://github.com/RuminantFarmSystems/MASM/pull/2791) - [minor change] [Animal] [NoInputChange] [NoOutputChange] Updates ration percentage values in example feed files to sum to exactly 100. -- [2833](https://github.com/RuminantFarmSystems/MASM/pull/2833) - [minor change] [Animal] [NoInputChange] [NoOutputChange] Remove unused animal_requirements.py file. -- [2815](https://github.com/RuminantFarmSystems/MASM/pull/2815) - [minor change] [All Non-Biophysical Modules] [NoInputChange] [NoOutputChange] Updates error messages raised to be clearer and more helpful for diagnosis and fixing. -- [2804](https://github.com/RuminantFarmSystems/MASM/pull/2804) - [minor change] [Tests] [NoInputChange] [NoOutputChange] Clears all mypy errors in test_field.py. -- [2828](https://github.com/RuminantFarmSystems/MASM/pull/2828) - [minor change] [DataValidator] [NoInputChange] [NoOutputChange] Refactors `validate_metadata()` to be less complex. -- [2819](https://github.com/RuminantFarmSystems/MASM/pull/2819) - [minor change] [Tests] [NoInputChange] [NoOutputChange] Clears all mypy errors in test_input_manager.py. -- [2836](https://github.com/RuminantFarmSystems/MASM/pull/2836) - [minor change] [Tests] [NoInputChange] [NoOutputChange] Clears all mypy errors in test_output_manager.py. -- [2826](https://github.com/RuminantFarmSystems/MASM/pull/2826) - [minor change] [Animal] [NoInputChange] [NoOutputChange] Adds functionality to data_padder, removes unecessary use of method in ration reporting. -- [2827](https://github.com/RuminantFarmSystems/MASM/pull/2827) - [minor change] [Metadata] [NoInputChange] [NoOutputChange] Updates ration-related metadata descriptions. -- [2849](https://github.com/RuminantFarmSystems/MASM/pull/2849) - [minor change] [Crop and Soil] [NoInputChange] [NoOutputChange] Update the property definition of dry matter percent. -- [2848](https://github.com/RuminantFarmSystems/MASM/pull/2848) - [minor change] [NoInputChange] [NoOutputChange] Justify `deepcopy()` usage. -- [2843](https://github.com/RuminantFarmSystems/MASM/pull/2843) - [minor change] [NoInputChange] [NoOutputChange] Fix Simple `#noqa`s in codebase. -- [2852](https://github.com/RuminantFarmSystems/MASM/pull/2852) - [minor change] [NoInputChange] [NoOutputChange] Fix AssertionError on `dev`. -- [2866](https://github.com/RuminantFarmSystems/MASM/pull/2866) - [minor change] [NoInputChange] [NoOutputChange] Clears all mypy errors in test_field_manager.py. -- [2863](https://github.com/RuminantFarmSystems/MASM/pull/2863) - [minor change] [NoInputChange] [NoOutputChange] Updates TaskManager to avoid using multiprocessing when running single tasks. -- [2867](https://github.com/RuminantFarmSystems/MASM/pull/2867) - [minor change] [NoInputChange] [NoOutputChange] Updates expand_data_temporally() util function to offer options of full simulation expansion and front-padding data. -- [2854](https://github.com/RuminantFarmSystems/MASM/pull/2854) - [minor change] [Emissions][OutputManager] [NoInputChange] [NoOutputChange] Update `emissions.py` filtering process and remove `use_filter_key_name` option in the OM filter. +- [2720](https://github.com/RuminantFarmSystems/RuFaS/pull/2720) - [minor change] [Emissions] [NoInputChange] [NoOutputChange] Adds FGF emissions reset when there's a harvest-kill operation and there's none of that feed left in storage. +- [2772](https://github.com/RuminantFarmSystems/RuFaS/pull/2772) - [minor change] [SimulationEngine] [NoInputChange] [NoOutputChange] Refactors `SimulationEngine`.`_daily_simulation()` to accommodate isolating modules. +- [2791](https://github.com/RuminantFarmSystems/RuFaS/pull/2791) - [minor change] [Animal] [NoInputChange] [NoOutputChange] Updates ration percentage values in example feed files to sum to exactly 100. +- [2813](https://github.com/RuminantFarmSystems/RuFaS/pull/2813) - [minor change] [Docs] [NoInputChange] [NoOutputChange] Updates branching and versioning policy docs. +- [2833](https://github.com/RuminantFarmSystems/RuFaS/pull/2833) - [minor change] [Animal] [NoInputChange] [NoOutputChange] Remove unused animal_requirements.py file. +- [2815](https://github.com/RuminantFarmSystems/RuFaS/pull/2815) - [minor change] [All Non-Biophysical Modules] [NoInputChange] [NoOutputChange] Updates error messages raised to be clearer and more helpful for diagnosis and fixing. +- [2804](https://github.com/RuminantFarmSystems/RuFaS/pull/2804) - [minor change] [Tests] [NoInputChange] [NoOutputChange] Clears all mypy errors in test_field.py. +- [2828](https://github.com/RuminantFarmSystems/RuFaS/pull/2828) - [minor change] [DataValidator] [NoInputChange] [NoOutputChange] Refactors `validate_metadata()` to be less complex. +- [2819](https://github.com/RuminantFarmSystems/RuFaS/pull/2819) - [minor change] [Tests] [NoInputChange] [NoOutputChange] Clears all mypy errors in test_input_manager.py. +- [2836](https://github.com/RuminantFarmSystems/RuFaS/pull/2836) - [minor change] [Tests] [NoInputChange] [NoOutputChange] Clears all mypy errors in test_output_manager.py. +- [2826](https://github.com/RuminantFarmSystems/RuFaS/pull/2826) - [minor change] [Animal] [NoInputChange] [NoOutputChange] Adds functionality to data_padder, removes unecessary use of method in ration reporting. +- [2827](https://github.com/RuminantFarmSystems/RuFaS/pull/2827) - [minor change] [Metadata] [NoInputChange] [NoOutputChange] Updates ration-related metadata descriptions. +- [2849](https://github.com/RuminantFarmSystems/RuFaS/pull/2849) - [minor change] [Crop and Soil] [NoInputChange] [NoOutputChange] Update the property definition of dry matter percent. +- [2848](https://github.com/RuminantFarmSystems/RuFaS/pull/2848) - [minor change] [NoInputChange] [NoOutputChange] Justify `deepcopy()` usage. +- [2843](https://github.com/RuminantFarmSystems/RuFaS/pull/2843) - [minor change] [NoInputChange] [NoOutputChange] Fix Simple `#noqa`s in codebase. +- [2852](https://github.com/RuminantFarmSystems/RuFaS/pull/2852) - [minor change] [NoInputChange] [NoOutputChange] Fix AssertionError on `dev`. +- [2866](https://github.com/RuminantFarmSystems/RuFaS/pull/2866) - [minor change] [NoInputChange] [NoOutputChange] Clears all mypy errors in test_field_manager.py. +- [2863](https://github.com/RuminantFarmSystems/RuFaS/pull/2863) - [minor change] [NoInputChange] [NoOutputChange] Updates TaskManager to avoid using multiprocessing when running single tasks. +- [2867](https://github.com/RuminantFarmSystems/RuFaS/pull/2867) - [minor change] [NoInputChange] [NoOutputChange] Updates expand_data_temporally() util function to offer options of full simulation expansion and front-padding data. +- [2854](https://github.com/RuminantFarmSystems/RuFaS/pull/2854) - [minor change] [Emissions][OutputManager] [NoInputChange] [NoOutputChange] Update `emissions.py` filtering process and remove `use_filter_key_name` option in the OM filter. - [2872](https://github.com/RuminantFarmSystems/RuFaS/pull/2872) - [minor change] [NoInputChange] [NoOutputChange] Adds information and links for onboarding videos. - [2850](https://github.com/RuminantFarmSystems/RuFaS/pull/2850) - [minor change] [NoInputChange] [NoOutputChange] Refactor `Pen.get_manure_stream()`. - [2902](https://github.com/RuminantFarmSystems/RuFaS/pull/2902) - [minor change] [NoInputChange] [NoOutputChange] Add v1.0.0 release notes. @@ -61,7 +62,7 @@ v1.0.0 - [2924](https://github.com/RuminantFarmSystems/RuFaS/pull/2924) - [minor change] [NoInputChange] [NoOutputChange] Updated advance purchase allowance to prevent excessive warnings for example run. - [2929](https://github.com/RuminantFarmSystems/RuFaS/pull/2929) - [minor change] [GraphGenerator] [NoInputChange] [NoOutputChange] Sanitizes non-numerical data sent to graph generator to allow graphing to occur despite. - [2925](https://github.com/RuminantFarmSystems/RuFaS/pull/2925) - [minor change] [NoInputChange] [NoOutputChange] Fix the `graph_and_report` option in report_generation.py. -- [2907](https://github.com/RuminantFarmSystems/RuFaS/pull/2907) - [minor change] [NoInputChange] [OutputChange] Fix the FarmGrownFeed Emissions unit issue. The mirror issue of [Fix FarmGrownFeed Emissions Unit on test #2908](https://github.com/RuminantFarmSystems/MASM/pull/2908) to update `dev`. +- [2907](https://github.com/RuminantFarmSystems/RuFaS/pull/2907) - [minor change] [NoInputChange] [OutputChange] Fix the FarmGrownFeed Emissions unit issue. The mirror issue of [Fix FarmGrownFeed Emissions Unit on test #2908](https://github.com/RuminantFarmSystems/RuFaS/pull/2908) to update `dev`. - [2934](https://github.com/RuminantFarmSystems/RuFaS/pull/2934) - [minor change] [NoInputChange] [NoOutputChange] [Animal][Reproduction] Refactor `Reproduction.execute_cow_ed_protocol()`. - [2948](https://github.com/RuminantFarmSystems/RuFaS/pull/2948) - [minor change] [Feeds][NoInputChange] [NoOutputChange] Removes feed id maximums in metadata properties. diff --git a/docs/_src/_wiki/Branching-Strategy-in-RuFaS.rst b/docs/_src/_wiki/Branching-Strategy-in-RuFaS.rst index 74c14d3f47..da42ad256c 100644 --- a/docs/_src/_wiki/Branching-Strategy-in-RuFaS.rst +++ b/docs/_src/_wiki/Branching-Strategy-in-RuFaS.rst @@ -1,7 +1,7 @@ Branching Strategy in RuFaS =========================== -In this wiki, we outline the branching strategy used in RuFaS, detailing +In this page, we outline the branching strategy used in RuFaS, detailing the purpose of each branch and the process for merging changes. Branches Overview @@ -12,31 +12,58 @@ Branches Overview - **Purpose**: Active development branch where new features and changes are implemented. + - **Usage**: All pull requests (PRs) are merged into ``dev``. This is - the main branch for ongoing development. -- **Approval**: Merging to ``dev`` requires 2 approvals. + the primary branch for ongoing development. + +- **Approval**: Merging to ``dev`` requires **2 approvals**. + +- **Note**: All the changes on ``dev`` are considered for the next release. + If something is **NOT** intended to be included in the next release, + it should be merged into a separate parking branch and not merged into ``dev`` + until it is ready for release. ``test`` ~~~~~~~~ -- **Purpose**: Intermediate branch used for integration and testing of - features before moving to ``main``. -- **Usage**: Changes from ``dev`` are periodically pulled into ``test`` - for vigorous testing. This ensures that new features and fixes are - properly tested before being considered stable. -- **Approval**: Merging to ``test`` requires at least 1 approval. +- **Purpose**: Intermediate branch used for **integration, validation, + and stabilization** prior to a release. + +- **Usage**: When preparing a release candidate, the current state of + ``dev`` is merged into ``test``. The ``test`` branch is then used for + validation and stabilization before releasing a new version. + + Once ``dev`` has been merged into ``test`` for a release candidate, + no new development work should be introduced into ``test``. Only bug + fixes discovered during testing should be applied. + +- **Approval**: ``test`` is locked and only admins can merge into it. ``main`` ~~~~~~~~ - **Purpose**: Primary branch representing the latest stable release that is ready for production. -- **Usage**: Once changes in ``test`` are confirmed to be stable, the - version number is updated, and updates are pulled into ``main``. The - ``main`` branch is locked, and only `Pooya - Hekmati `__ and `Kristan - Reed `__ have the permissions to merge - PRs into it. + +- **Usage**: Once changes in ``test`` are confirmed to be stable and the + version number has been updated, updates are pulled into ``main``. + +- **Permissions**: The ``main`` branch is locked, and only + repo admins have permission to merge pull requests into it. + +``scientific_documentation_updates`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- **Purpose**: Branch used for updates to the **scientific documentation** + that do not require changes to the RuFaS codebase. + +- **Usage**: Documentation updates may be committed directly to this + branch and merged into ``main`` without going through the ``test`` + branch. + +- **Synchronization**: After merging into ``main``, the changes must + also be merged into ``dev`` to ensure documentation remains consistent + across development branches. Merging Process --------------- @@ -44,50 +71,107 @@ Merging Process Merging to ``dev`` ~~~~~~~~~~~~~~~~~~ -1. **Develop**: Create feature branches off ``dev`` to work on new - features or fixes. -2. **Submit PR**: Once the feature is ready, create a pull request to - merge it into ``dev``. -3. **Review**: The code is reviewed following the `code review - process `__ - in RuFaS. -4. **Merge**: After approval, the PR is merged into ``dev``. +1. **Develop** + + - Create feature branches from ``dev`` to implement new features, + bug fixes, or improvements. + +2. **Submit PR** + + - Once development is complete, submit a pull request to merge the + feature branch into ``dev``. + +3. **Review** + + - Code is reviewed following the + `code review process `__ + used in RuFaS. + +4. **Merge** + + - After receiving the required approvals, the PR is merged into + ``dev``. Merging to ``test`` ~~~~~~~~~~~~~~~~~~~ -1. **Periodic Updates**: Periodically, pull changes from ``dev`` into - ``test``. -2. **Testing**: Conduct rigorous testing on the ``test`` branch to - ensure all features and fixes are stable. -3. **Feedback**: Address any issues found during testing by pushing - fixes to ``dev`` and then merging the updates back into ``test``. +1. **Prepare a Release Candidate** + + - When the development team decides to prepare a release, + update the version number in ``pyproject.toml`` on the ``dev`` + branch and merge ``dev`` into ``test``. + +2. **Testing Phase** + + - Conduct rigorous testing on the ``test`` branch to verify model + correctness, integration stability, and expected behavior. + +3. **Handling Issues During Testing** + + If an issue is discovered during testing: + + - Create a **fix branch from ``test``**. + - Implement the fix in that branch. + - Submit a PR to merge the fix into ``test``. + - After the fix is merged into ``test``, create a PR to merge the + same fix back into ``dev`` so both branches remain synchronized. + +4. **Continue Stabilization** + + - Repeat this process until the ``test`` branch is confirmed to be + stable and ready for release. Merging to ``main`` ~~~~~~~~~~~~~~~~~~~ -1. **Stability Confirmation**: Once the ``test`` branch is confirmed to - be stable, update the version number in both ``TaskManager`` and the - change log. :doc:`RuFaS Versioning Policy ` -2. **Pull Updates**: Pull the stable updates from ``test`` into - ``main``. -3. **Approval**: Only `Pooya - Hekmati `__ and `Kristan - Reed `__ can merge PRs into ``main`` - to ensure high-quality, stable releases. +1. **Merge Version Update into Test** + + - Merge the updated ``dev`` branch into ``test`` as part of the + release preparation. + +2. **Stability Confirmation** + + - Confirm that the ``test`` branch has passed validation and + stabilization testing. + +3. **PML Approval** + + - The **Project Management Lead (PML)** must approve the release and + the release notes before the merge to ``main`` is performed. + +4. **Merge to Main** + + - Pull the stable updates from ``test`` into ``main``. + +5. **Tag the Release** + + - Create a Git tag corresponding to the version number + (for example ``v1.2.0``). Best Practices -------------- -- **Consistent Testing**: Ensure thorough testing is done in ``test`` - before merging into ``main``. -- **Clear Communication**: Keep all team members informed about the - status of each branch and any important changes. -- **Documentation**: Maintain clear and up-to-date documentation for all - changes and testing procedures. -- **Review and Approval**: Adhere to the :doc:`code review guidelines ` - to maintain code quality and stability. - -By following this branching strategy, we ensure a clear and structured -workflow that supports continuous integration and delivery, maintaining -the high standards of code quality in RuFaS. +- **Consistent Testing** + + Ensure thorough validation is completed in ``test`` before merging + into ``main``. + +- **Branch Consistency** + + Fixes applied during the testing phase must always be merged back into + ``dev`` to prevent branch divergence. + +- **Clear Communication** + + Keep all team members informed about the status of release candidates + and branch updates. + +- **Documentation** + + Maintain clear and up-to-date documentation for changes and testing + procedures. + +- **Review and Approval** + + Adhere to the :doc:`Code Review Guidelines ` to maintain + code quality and model integrity. \ No newline at end of file diff --git a/docs/_src/_wiki/RuFaS-Versioning-Policy.rst b/docs/_src/_wiki/RuFaS-Versioning-Policy.rst index 5a11dc509f..ecb6df5adc 100644 --- a/docs/_src/_wiki/RuFaS-Versioning-Policy.rst +++ b/docs/_src/_wiki/RuFaS-Versioning-Policy.rst @@ -2,118 +2,197 @@ RuFaS Versioning Policy ======================= RuFaS follows a **Semantic Versioning** policy to ensure clear -communication of changes and maintain compatibility across updates. This -page outlines how we handle versioning, branch structure, and the -process for updating version numbers in RuFaS. +communication of changes and maintain compatibility across updates. +This page outlines how version numbers are assigned, how releases are +prepared, and how changes are documented. Semantic Versioning in RuFaS ---------------------------- -RuFaS adheres to the `Semantic Versioning -(SemVer) `__ scheme to manage and communicate -changes across the project. The version format is as follows: -``MAJOR.MINOR.PATCH``. +RuFaS follows the `Semantic Versioning (SemVer) `__ +standard. Versions follow the format: -- **MAJOR version** (``X.0.0``): Incremented when we make changes that - are **backward-incompatible** or introduce significant new - functionality that may require users to adjust their code or workflow. +``MAJOR.MINOR.PATCH`` -- **MINOR version** (``0.Y.0``): Incremented when new features are added - that are **backward-compatible**. This allows users to upgrade without - needing to modify their existing setup. +- **MAJOR version** (``X.0.0``) -- **PATCH version** (``0.0.Z``): Incremented for **backward-compatible - bug fixes** or minor improvements that don't add new features but - improve stability or fix known issues. + Incremented when changes introduce **backward-incompatible behavior** + that requires users to modify their workflows, inputs, or scripts. + +- **MINOR version** (``X.Y.0``) + + Incremented when **new functionality is added in a backward-compatible + way**. Existing simulations should continue to work without requiring + modification. + +- **PATCH version** (``X.Y.Z``) + + Incremented for **backward-compatible bug fixes and stability + improvements**. These updates may correct model behavior but must not + require users to change inputs or workflows. Example ~~~~~~~ -For a release version ``2.1.4``: +For a release version ``2.3.5``: + +- **2** indicates a major update introducing incompatible changes. +- **3** indicates new backward-compatible functionality. +- **5** indicates bug fixes or minor improvements. + +Compatibility in RuFaS +---------------------- + +In the context of RuFaS, compatibility primarily concerns **model +inputs, outputs, and user workflows**. + +Typical interpretations include: + +- **InputChange** + + Indicates whether a change modifies model inputs. This may include + new required fields, changed input structures, or modified semantics. + +- **OutputChange** + + Indicates whether model outputs change. Output changes may result + from bug fixes, improved calculations, or new outputs being added. + +Guidelines +~~~~~~~~~~ -- **2**: MAJOR update indicating a significant or breaking change. -- **1**: MINOR update indicating the addition of new features. -- **4**: PATCH update indicating minor fixes or improvements. +- **InputChange = Yes** + + Usually requires a **MAJOR version bump**, unless the change is purely + additive and does not break existing inputs. + +- **OutputChange = Yes** + + May appear in **PATCH** releases when correcting model behavior. + Structural output changes may require a **MINOR** or **MAJOR** version + bump depending on their impact. Branch Structure ---------------- -RuFaS follows a structured branching model to manage development, -testing, and production-ready code. The three main branches are: +RuFaS uses three primary branches to manage development and releases. + +- **dev** + + Primary development branch where new features, improvements, and + fixes are implemented. + +- **test** + + Integration and stabilization branch used to validate a release + candidate before publishing a new version. + +- **main** + + Stable branch representing the officially released production version + of RuFaS. + +See :doc:`Branching Strategy ` +for details about how these branches interact. + +Version Location +---------------- + +The RuFaS version number is stored in the ``pyproject.toml`` file. -- **dev**: The primary development branch where new features, bug fixes, - and improvements are implemented. Changes here are not considered - stable and may undergo significant modifications. +Example: -- **test**: Once features are completed and pass initial testing, they - are merged into the ``test`` branch. This branch is used for broader - testing, including integration tests and any QA processes. +.. code-block:: toml -- **main**: The stable release branch. Only code that has been - thoroughly tested and reviewed is merged into ``main``. This is the - production-ready version of RuFaS that users rely on. + [project] + version = "1.2.0" -See :doc:`Branching Strategy ` -for more details. +This value represents the official version of RuFaS once the release is +merged into ``main``. Version Number Update Process ----------------------------- -Every time we merge the **test** branch into the **main** branch, we -follow the steps below to update the version number and track the -changes. +Each RuFaS release follows a structured process to ensure version +numbers and release history remain consistent. -Steps: -~~~~~~ +Steps +~~~~~ -1. **Decide on the Version Increment**: +1. **Determine Version Increment** - - Evaluate the changes introduced since the last merge. Based on the - nature of the changes (major, minor, or patch), increment the - version number accordingly following the **Semantic Versioning** - guidelines. + - PML reviews all changes introduced since the previous release. + - PML decides whether the release should increment **MAJOR**, **MINOR**, or + **PATCH** according to Semantic Versioning. -2. **Update Version in TaskManager**: +2. **Update Version in ``dev``** - - Navigate to the version configuration file in the TaskManager and - update the version number to reflect the changes. + - Repo Admin updates the ``version`` field in ``pyproject.toml`` on the ``dev`` + branch. -3. **Changelog Updates Automatically**: +3. **Create Release Candidate** - - The changelog is automatically updated, reflecting all the pull - requests merged up to this point. The new version number simply - marks the last pull request included in the current version. + - Repo Admin merges ``dev`` into ``test`` to create a release candidate. -4. **Tag the Release**: +4. **Stabilization Testing** - - Once the version is updated, create a new Git tag with the version - number (e.g., ``v1.2.0``) to mark the release in the **main** - branch. + - Validate the release candidate on the ``test`` branch. + - If issues are discovered: + + - Create a fix branch from ``test``. + - Merge the fix into ``test``. + - Merge the same fix back into ``dev``. + +5. **PML Approval** + + - The **Project Management Lead (PML)** must approve the release and + the release notes before the release is finalized. -Example Workflow: -~~~~~~~~~~~~~~~~~ +6. **Merge into Main** -- A new feature is completed and tested in the ``dev`` branch. -- The feature is merged into ``test`` for broader testing and - integration validation. -- After successful testing, The version number is incremented in - ``TaskManager`` and change log. -- The ``test`` branch is merged into ``main``. + - Repo Admin merges ``test`` into ``main`` once stabilization testing is complete. + +7. **Tag the Release** + + - Repo Admin creates a Git tag corresponding to the version number, for example: + + :: + + v1.2.0 Changelog Format ---------------- -Each entry in the Changelog follows this format: +Each entry in the changelog must follow the format below: + +:: + + - [123](https://github.com/RuminantFarmSystems/RuFaS/pull/123) - [Major change/minor change] [Impact Area] [InputChange/NoInputChange] [OutputChange/NoOutputChange] Short description of the change or feature. + +Fields +~~~~~~ + +- **PR Number** + + Link to the pull request that introduced the change. + +- **Type of Change** + + Indicates whether the change is a **major change** or **minor change**. + +- **Impact Area** + + The RuFaS component affected (for example ``Animal Module``, + ``Manure Module``). + +- **InputChange** + + ``InputChange`` if the change modifies model inputs; otherwise ``NoInputChange``. + +- **OutputChange** + + ``OutputChange`` if the change modifies model outputs; otherwise ``NoOutputChange``. -- **PR #**: Provide the pull request number (e.g., - ``[123](https://github.com/RuminantFarmSystems/RuFaS/pull/123)``). -- **Type of Change**: Indicate if it is a major or minor change (e.g., - ``[Major change]`` or ``[Minor change]``). -- **Impact Area**: Specify which part of the codebase is affected (e.g., - ``[Animal Module]``, ``[Manure Module]``, etc.). -- **Description**: Provide a concise, informative description of the - changes. +- **Description** -By following this process, RuFaS ensures that versioning is consistent, -changes are tracked transparently, and users are well-informed about -updates and their impacts. + A concise description of the change or feature. \ No newline at end of file