build based on f7ea390

dev/.documenter-siteinfo.json

@@ -1 +1 @@
-{"documenter":{"julia_version":"1.10.4","generation_timestamp":"2024-08-16T15:11:47","documenter_version":"1.5.0"}}
+{"documenter":{"julia_version":"1.10.5","generation_timestamp":"2024-08-30T21:01:23","documenter_version":"1.6.0"}}

dev/devdocs/style/index.html

@@ -6,4 +6,4 @@
 #########
 
 # Subsection
-#-----------</code></pre><h2 id="Guidelines-for-pull-requests"><a class="docs-heading-anchor" href="#Guidelines-for-pull-requests">Guidelines for pull requests</a><a id="Guidelines-for-pull-requests-1"></a><a class="docs-heading-anchor-permalink" href="#Guidelines-for-pull-requests" title="Permalink"></a></h2><p>Every pull request to Catlab should be reviewed by at least one person. Following are some things to check when making a PR yourself or reviewing someone else&#39;s PR. The goal of this list is to ensure that the Catlab codebase is robust and maintainable. When any of these guidelines are violated, it should be documented in a comment on the PR page.</p><p><strong>Note</strong>: This list only includes the mechanical things. When a reviewing a PR you should always use your own judgment in asking questions and making comments about API and algorithm design. That&#39;s the hard part!</p><h3 id="Tests-and-code-coverage"><a class="docs-heading-anchor" href="#Tests-and-code-coverage">Tests and code coverage</a><a id="Tests-and-code-coverage-1"></a><a class="docs-heading-anchor-permalink" href="#Tests-and-code-coverage" title="Permalink"></a></h3><ul><li>Enhancements (new features) must have accompanying unit tests</li><li>Bug fixes should come with unit tests exposing the bug, unless producing a minimal example is unusually difficult</li><li>Do not delete existing unit tests, unless you have a very good reason (e.g., the relevant functionality is being moved to another package), which is documented in the PR</li><li>If you are adding a new module, make sure to add the test module to the test runner (<code>test/runtests.jl</code> or file included therein)</li><li>Code coverage on the Catlab repo exceeds 90% and we try to keep it that way. We do not insist on 100% coverage, which is impractical, nor do we set a hard threshold applicable to all PRs, but generally you should aim for 90%+ code coverage. Any reductions in test coverage should be justified in the PR.</li></ul><h3 id="Documentation"><a class="docs-heading-anchor" href="#Documentation">Documentation</a><a id="Documentation-1"></a><a class="docs-heading-anchor-permalink" href="#Documentation" title="Permalink"></a></h3><ul><li>All exported functions, types, and constants must have docstrings</li><li>Docstrings should be written in complete sentences, with correct capitalization and punctuation. Likewise for comments, except for fragmentary end-of-line comments.</li><li>Where possible, provide citations for constructions and algorithms that you implement. This reflects good scholarly values and also aids the understanding of your code by other people.</li></ul><h3 id="Version-control"><a class="docs-heading-anchor" href="#Version-control">Version control</a><a id="Version-control-1"></a><a class="docs-heading-anchor-permalink" href="#Version-control" title="Permalink"></a></h3><ul><li>Commit messages should be informative and be written in complete sentences</li><li>Avoid one-word commit messages like &quot;fix&quot; or &quot;bug&quot;. If you need to make very simple fixes on your branch, amend a previous commit and force push.</li><li>Avoid repeatedly merging the main branch back into your PR branch. Instead, rebase off main and force push.</li></ul><h3 id="Backwards-compatibility"><a class="docs-heading-anchor" href="#Backwards-compatibility">Backwards compatibility</a><a id="Backwards-compatibility-1"></a><a class="docs-heading-anchor-permalink" href="#Backwards-compatibility" title="Permalink"></a></h3><p>Reflecting Catlab&#39;s dual status as a research project and a user-facing library, we want to give ourselves space to experiment while also not annoying our users and each other by needlessly breaking things.</p><ul><li>Like other Julia packages, Catlab aims to follow <a href="https://pkgdocs.julialang.org/v1/compatibility/">semantic versioning</a></li><li>All else equal, it is better to make breaking changes to new APIs, especially very new ones, than old APIs</li><li>If you plan to make major breaking changes, please coordinate with the senior developers to ensure that it makes senses and aligns with the release schedule</li></ul></article><nav class="docs-footer"><a class="docs-footer-prevpage" href="../../apis/programs/">« Programs</a><div class="flexbox-break"></div><p class="footer-message">Powered by <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> and the <a href="https://julialang.org/">Julia Programming Language</a>.</p></nav></div><div class="modal" id="documenter-settings"><div class="modal-background"></div><div class="modal-card"><header class="modal-card-head"><p class="modal-card-title">Settings</p><button class="delete"></button></header><section class="modal-card-body"><p><label class="label">Theme</label><div class="select"><select id="documenter-themepicker"><option value="auto">Automatic (OS)</option><option value="documenter-light">documenter-light</option><option value="documenter-dark">documenter-dark</option><option value="catppuccin-latte">catppuccin-latte</option><option value="catppuccin-frappe">catppuccin-frappe</option><option value="catppuccin-macchiato">catppuccin-macchiato</option><option value="catppuccin-mocha">catppuccin-mocha</option></select></div></p><hr/><p>This document was generated with <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> version 1.5.0 on <span class="colophon-date" title="Friday 16 August 2024 15:11">Friday 16 August 2024</span>. Using Julia version 1.10.4.</p></section><footer class="modal-card-foot"></footer></div></div></div></body></html>
+#-----------</code></pre><h2 id="Guidelines-for-pull-requests"><a class="docs-heading-anchor" href="#Guidelines-for-pull-requests">Guidelines for pull requests</a><a id="Guidelines-for-pull-requests-1"></a><a class="docs-heading-anchor-permalink" href="#Guidelines-for-pull-requests" title="Permalink"></a></h2><p>Every pull request to Catlab should be reviewed by at least one person. Following are some things to check when making a PR yourself or reviewing someone else&#39;s PR. The goal of this list is to ensure that the Catlab codebase is robust and maintainable. When any of these guidelines are violated, it should be documented in a comment on the PR page.</p><p><strong>Note</strong>: This list only includes the mechanical things. When a reviewing a PR you should always use your own judgment in asking questions and making comments about API and algorithm design. That&#39;s the hard part!</p><h3 id="Tests-and-code-coverage"><a class="docs-heading-anchor" href="#Tests-and-code-coverage">Tests and code coverage</a><a id="Tests-and-code-coverage-1"></a><a class="docs-heading-anchor-permalink" href="#Tests-and-code-coverage" title="Permalink"></a></h3><ul><li>Enhancements (new features) must have accompanying unit tests</li><li>Bug fixes should come with unit tests exposing the bug, unless producing a minimal example is unusually difficult</li><li>Do not delete existing unit tests, unless you have a very good reason (e.g., the relevant functionality is being moved to another package), which is documented in the PR</li><li>If you are adding a new module, make sure to add the test module to the test runner (<code>test/runtests.jl</code> or file included therein)</li><li>Code coverage on the Catlab repo exceeds 90% and we try to keep it that way. We do not insist on 100% coverage, which is impractical, nor do we set a hard threshold applicable to all PRs, but generally you should aim for 90%+ code coverage. Any reductions in test coverage should be justified in the PR.</li></ul><h3 id="Documentation"><a class="docs-heading-anchor" href="#Documentation">Documentation</a><a id="Documentation-1"></a><a class="docs-heading-anchor-permalink" href="#Documentation" title="Permalink"></a></h3><ul><li>All exported functions, types, and constants must have docstrings</li><li>Docstrings should be written in complete sentences, with correct capitalization and punctuation. Likewise for comments, except for fragmentary end-of-line comments.</li><li>Where possible, provide citations for constructions and algorithms that you implement. This reflects good scholarly values and also aids the understanding of your code by other people.</li></ul><h3 id="Version-control"><a class="docs-heading-anchor" href="#Version-control">Version control</a><a id="Version-control-1"></a><a class="docs-heading-anchor-permalink" href="#Version-control" title="Permalink"></a></h3><ul><li>Commit messages should be informative and be written in complete sentences</li><li>Avoid one-word commit messages like &quot;fix&quot; or &quot;bug&quot;. If you need to make very simple fixes on your branch, amend a previous commit and force push.</li><li>Avoid repeatedly merging the main branch back into your PR branch. Instead, rebase off main and force push.</li></ul><h3 id="Backwards-compatibility"><a class="docs-heading-anchor" href="#Backwards-compatibility">Backwards compatibility</a><a id="Backwards-compatibility-1"></a><a class="docs-heading-anchor-permalink" href="#Backwards-compatibility" title="Permalink"></a></h3><p>Reflecting Catlab&#39;s dual status as a research project and a user-facing library, we want to give ourselves space to experiment while also not annoying our users and each other by needlessly breaking things.</p><ul><li>Like other Julia packages, Catlab aims to follow <a href="https://pkgdocs.julialang.org/v1/compatibility/">semantic versioning</a></li><li>All else equal, it is better to make breaking changes to new APIs, especially very new ones, than old APIs</li><li>If you plan to make major breaking changes, please coordinate with the senior developers to ensure that it makes senses and aligns with the release schedule</li></ul></article><nav class="docs-footer"><a class="docs-footer-prevpage" href="../../apis/programs/">« Programs</a><div class="flexbox-break"></div><p class="footer-message">Powered by <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> and the <a href="https://julialang.org/">Julia Programming Language</a>.</p></nav></div><div class="modal" id="documenter-settings"><div class="modal-background"></div><div class="modal-card"><header class="modal-card-head"><p class="modal-card-title">Settings</p><button class="delete"></button></header><section class="modal-card-body"><p><label class="label">Theme</label><div class="select"><select id="documenter-themepicker"><option value="auto">Automatic (OS)</option><option value="documenter-light">documenter-light</option><option value="documenter-dark">documenter-dark</option><option value="catppuccin-latte">catppuccin-latte</option><option value="catppuccin-frappe">catppuccin-frappe</option><option value="catppuccin-macchiato">catppuccin-macchiato</option><option value="catppuccin-mocha">catppuccin-mocha</option></select></div></p><hr/><p>This document was generated with <a href="https://github.com/JuliaDocs/Documenter.jl">Documenter.jl</a> version 1.6.0 on <span class="colophon-date" title="Friday 30 August 2024 21:01">Friday 30 August 2024</span>. Using Julia version 1.10.5.</p></section><footer class="modal-card-foot"></footer></div></div></div></body></html>