Development Process

CFDverify’s development process is described here. All regular development to CFD is expected to follow this process to ensure the quality of the developed software.

  1. Initiate: Code contributions should be tied to an issue opened on the CFDverify GitHub. This allows code maintainers a chance to review the proposed contributions for consistency with CFDverify’s development goals before effort is expended. Issues, in conjunction with pull requests, also provide documentation of the development process for CFDverify for traceability of features and may be useful in identifying and eliminating bugs.

  2. Develop: Contributions should be developed with the following attributes in mind to facilitate a speedy review process. The design philosophy for CFDverify is laid out in the originating ASME VVUQ conference paper.

    1. Style: New code shall follow the style of CFDverify. For now, CFDverify style means following PEP 8 for code and numpydoc for docstrings.

    2. Documentation: All contributions shall be documented. New code should include in line comments where needed, function and class docstrings, and appropriate Sphinx documentation.

    3. Unit tests: All new code shall have unit tests. The goal of CFDverify is to have 100% coverage, but the precise extent of tests required for new code will be determined on a case-by-case basis.

    4. Regression tests: New methods should add regression tests based on primary literature of the method.

  3. Review: Pull requests shall be reviewed by a maintainer. Currently, CFDverify is mainly developed and maintained by a single individual, so it is expected he may serve both roles.

  4. Merge: Reviewed and accepted code shall be merged into a development branch of CFDverify.

  5. Deploy: Development branches shall be merged into the main branch of CFDverify following semantic versioning 2.0.0 (see Semantic Versioning).

Semantic Versioning

CFDverify uses semantic versioning for identifying releases. Currently, CFDverify is in initial development, so the public application programming interface (API) may change at any time.