This repository is https://github.com/openwfm/WRF-SFIRE master branch.
A mirror with a graphical log is at https://repo.or.cz/git-browser/by-commit.html?r=WRF-SFIRE.git
The current released version of WRF-SFIRE is the version W4.4-S0.1.
Release information about this version is not available yet.
The used version of WRF is 4.4 (see release information).
The version of SFIRE is 0.1.
We are excited to share a significant development in our project's versioning system. As we release the official 0.1 version of our code, we want to introduce you to an enhanced versioning approach that incorporates the relationship between SFIRE code and WRF code. Moving forward, our versioning system will consist of two components: the Weather Research and Forecasting (WRF) code version and the Wildfire Spread Simulation (SFIRE) code version.
The semantic versioning scheme (https://semver.org) we have adopted is designed to provide clarity and context about the interconnectedness of our code with the WRF and SFIRE codes. Each version will be represented in the following format: Wx.y-Si.j, where:
Wx.y denotes the version of the WRF code on which our codebase relies. For example, W4.4 represents version 4.4 of the WRF code. This component indicates the underlying framework that drives our code's functionality.
Si.j represents the version of our code. For instance, S0.1 signifies the first official release (version 0.1) of our code, SFIRE. This component focuses on the development and evolution of our code specifically.
This enhanced versioning system offers several advantages to our community:
Clear relationship between codes: By incorporating the WRF version alongside our code's version, we provide a transparent representation of the underlying codebase that supports our functionality. This clarity ensures that users can easily identify the connection between different versions.
Compatibility and integration: The WRF-SFIRE integration necessitates version compatibility between the two codes. By explicitly denoting the WRF version, we ensure that users can determine which versions of WRF are compatible with specific releases of our code, thereby facilitating seamless integration.
Streamlined updates: With the enhanced versioning system, it becomes simpler to track and understand the evolution of both the WRF and SFIRE codes. This knowledge empowers users to make informed decisions about updating either component, based on their specific requirements and compatibility constraints.
Precise communication: When discussing our code or reporting issues, the enhanced versioning system enables clear and concise communication by explicitly referring to the WRF and SFIRE versions being utilized. This precision helps in resolving potential issues more efficiently.
We have implemented a new branch management strategy to improve code organization and streamline the development process. This strategy involves the use of specific branches with defined purposes and guidelines. The key branches in our repository are:
Master Branch: The master branch contains officially released content and serves as a stable version of the codebase. Commits on this branch are tagged with specific release tags following the standard format: Wx.y-Si.j.
Release Branch: The release branch is used to merge developments of SFIRE from develop-x branches. It acts as an intermediary branch before merging into the master branch. Merging the release branch into master leads to an increase in the Si.j part of the version number.
Merge-WRF Branch: The merge-WRF branch is responsible for merging upgrades made on the WRF side to the WRF-SFIRE codebase. This branch facilitates the integration of improvements from the WRF repository into our codebase. Merging the merge-WRF branch into master will increase the Wx.y part of the version number.
Develop-x Branches: The develop-x branches are issue-based branches, where x refers to an open issue on GitHub. Each develop-x branch focuses on addressing a specific issue. Once a develop-x branch has been merged into the release branch and subsequently into the master branch, the related issue is closed automatically by the corresponding commit.
The branch workflow for upgrading SFIRE can be summarized as follows:
Feature Development: Developers create issue-based branches (develop-x) to work on specific issues identified on GitHub related to SFIRE enhancements.
Merge to Release Branch: Once the development work on an issue is completed, the corresponding develop-x branch is merged into the release branch.
Release to Master Branch: Periodically, the changes from the release branch are merged into the master branch to create stable releases. This merge increases the Si.j version number, where i represents the SFIRE version.
By following this workflow, we ensure that SFIRE enhancements undergo thorough development, testing, and integration before being released in a stable version.
The branch workflow for upgrading the WRF version can be summarized as follows:
Merge WRF Upgrades: Updates from the WRF repository are merged into the merge-WRF branch to incorporate improvements from the WRF side into our codebase.
Merge to Master Branch: The merge-WRF branch is periodically merged into the master branch to integrate the WRF upgrades. This merge increases the Wx.y version number, where x represents the major WRF version and y represents the minor WRF version.
By following this workflow, we ensure that the WRF-SFIRE codebase remains up to date with the latest enhancements and features from the WRF project.
Before any merge into the master branch, we apply a rigorous regression testing protocol, described in the next section.
By following this branch management workflow and incorporating regression testing, we aim to ensure a controlled and systematic approach to releasing stable versions while maintaining code integrity.
In our ongoing commitment to quality assurance and delivering a reliable codebase, we are excited to introduce regression testing as an integral part of our development process. Regression testing is a systematic approach to retesting previously implemented functionalities to ensure that recent changes or additions to the codebase have not introduced unintended side effects or regressions.
By incorporating regression testing, we aim to achieve the following benefits:
Ensure Code Stability: Regression testing allows us to verify that existing functionalities continue to work as intended after implementing new features or making code modifications. This helps us identify and fix any unforeseen issues that may have arisen due to recent changes.
Prevent Unintended Side Effects: Through a comprehensive suite of regression tests, we can proactively detect any unintended side effects or regressions that could potentially impact the performance, reliability, or functionality of our codebase.
Safeguard Against Future Changes: By maintaining a robust regression test suite, we establish a safety net that protects against future code modifications or updates. The tests serve as a baseline to ensure that future changes do not inadvertently break existing functionalities.
To implement regression testing, our development team will:
In our ongoing efforts to maintain a high-quality codebase, we are introducing coding and linting rules that are aligned with the WRF (Weather Research and Forecasting) coding rules. These rules ensure consistent and reliable code across our project, following industry best practices and the established standards of the WRF community.
We have established a set of coding and linting rules that are specifically designed to comply with the WRF coding rules and inpired by FORTRAN90/95 coding conventions. These rules cover various aspects of coding style, naming conventions, documentation practices, and more. By adhering to these rules, we aim to improve code consistency, readability, and collaboration within the project, while also maintaining compatibility with the broader WRF ecosystem.
To enforce these rules, we have integrated automated code analysis tools into our development process. These tools will check the code against the defined rules and provide immediate feedback to developers, allowing them to address any violations and ensure that the codebase aligns with the WRF coding standards.
In addition to the introduction of coding and linting rules, we are implementing a regular code quality evaluation process. This process involves periodic assessments of the codebase to identify areas for improvement, detect potential issues, and ensure compliance with the WRF coding guidelines. To enforce coding standards and best practices, we utilize the Flint Python library. Flint allows us to perform automated code analysis and evaluate code quality quantitatively. In addition to the default rules provided by Flint, we have implemented custom rules specific to our project. These rules align with the WRF coding guidelines and reflect our coding conventions.
Through this evaluation process, we will proactively address any code quality concerns, optimize performance, enhance maintainability, and strengthen the overall stability of the codebase. By aligning with the WRF coding rules, we aim to uphold the highest standards of code quality and facilitate seamless integration with the wider WRF community.
We highly value the involvement and expertise of our community in maintaining code quality. We encourage all community members to embrace the coding and linting rules based on the WRF coding rules, provide feedback, and contribute to the continuous improvement of our codebase.
Your contributions, such as code reviews, suggestions, and bug reports, are invaluable in helping us ensure the highest level of code quality and deliver an exceptional experience to our users, while maintaining compatibility and coherence with the WRF ecosystem.
Link to issues always using:
organization/repository#number
For instance: wirc-sjsu/WRF-SFIRE#4 or openwfm/WRF-SFIRE#86
This will prevent linking to different issues in both organizations with the same number. Links created for commits dated before the issue seems to not cause a problem.
Standalone is included but have not started on it yet. Branches balbi and dvm_branch were carried over but they are not merged into master or tested yet because they were not merged into master in wrf-fire. Also I do not know how to test dvm_branch. I can't do real problems yet, that requires pushing data through current WPS, which Adam and Angel are working on.