Generated main for commit 2fbf211

Merge: 024511d 51b9b97 Author: Paul Wilson <[email protected]> Merge pull request #341 from abachma2/branch-change
cyclus · Mar 22, 2024 · f8739aa · f8739aa
1 parent f4b42f2
commit f8739aa
Show file tree

Hide file tree

Showing 14 changed files with 21 additions and 21 deletions.
diff --git a/_sources/kernel/build_from_source.rst.txt b/_sources/kernel/build_from_source.rst.txt
@@ -45,11 +45,11 @@ For the git uninitiated, one must perform the following steps to acquire |cyclus
 
 Note that each |cyclus| repository has **two** branches:
 
-  * master -- the latest stable release of the library
+  * main -- the latest stable release of the library
   * develop -- the latest working copy that passes all tests
 
 The above branches are synchronized with each other, and should be used in tandem
-(i.e., use master (|Cyclus|) with master (Cycamore) or develop with develop only).
+(i.e., use main (|Cyclus|) with main (Cycamore) or develop with develop only).
 
 .. _`Set Up git`: http://help.github.com/linux-set-up-git/
 

diff --git a/_sources/kernel/contributing_to_cyclus.rst.txt b/_sources/kernel/contributing_to_cyclus.rst.txt
@@ -38,7 +38,7 @@ only after:
 * Your code has been reviewed by another developer.
 
 Code from the "develop" branch generally must pass even more rigorous checks
-before being integrated into the "master" branch. Hotfixes would be a
+before being integrated into the "main" branch. Hotfixes would be a
 possible exception to this.
 
 Keeping Your Fork Up To Date
@@ -50,11 +50,11 @@ Keeping Your Fork Up To Date
   compilable) progress when we are not yet ready for the code to become
   'production'.
 
-* Keep your own "master" and "develop" branches in sync with the upstream
-  repository's "master" and "develop" branches. The master branch should
+* Keep your own "main" and "develop" branches in sync with the upstream
+  repository's "main" and "develop" branches. The main branch should
   always be the 'stable' or 'production' release of |cyclus|.
 
-   - Pull the most recent history from the upstream repository "master"
+   - Pull the most recent history from the upstream repository "main"
      and/or "develop" branches before you merge changes into your
      corresponding local branch. Consider doing a rebase pull instead of
      a regular pull or 'fetch and merge'.  For example::
@@ -63,7 +63,7 @@ Keeping Your Fork Up To Date
        git pull --rebase upstream develop
 
 * As you do development on topic branches in your own fork, consider
-  rebasing the topic branch onto the "master" and/or "develop"  branches
+  rebasing the topic branch onto the "main" and/or "develop"  branches
   after *pulls* from the upstream repository rather than merging the pulled
   changes into your branch.  This will help maintain a more linear (and clean)
   history.  *Please see caution about rebasing below*.  For example::
@@ -168,7 +168,7 @@ Reviewing a Pull Request
   - Accept the Pull Request
 
     - In general, **every commit** (notice this is not 'every push') to the
-      "develop" and "master" branches should compile and pass tests. This
+      "develop" and "main" branches should compile and pass tests. This
       is guaranteed by using a NON-fast-forward merge during the pull request
       acceptance process.
 

diff --git a/_sources/kernel/style_guide.rst.txt b/_sources/kernel/style_guide.rst.txt
@@ -26,7 +26,7 @@ documentation by running `make cyclusdoc` instead of `make all` or `make`.
 .. _`Google C++ Style Guide`: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
 .. _`Google Python Style Guide`: http://google-styleguide.googlecode.com/svn/trunk/pyguide.html
 .. _`Artistic Style` : http://astyle.sourceforge.net
-.. _`settings` : http://github.com/cyclus/cyclus/blob/master/misc/.astylerc
+.. _`settings` : http://github.com/cyclus/cyclus/blob/main/misc/.astylerc
 .. _`limits and bugs` : https://sourceforge.net/p/astyle/bugs/
 .. _`Cpplint` : http://google-styleguide.googlecode.com/svn/trunk/cpplint/
 .. _`Pylint` : http://www.pylint.org/

diff --git a/_sources/user/tutorial/run_cyclus_native.rst.txt b/_sources/user/tutorial/run_cyclus_native.rst.txt
@@ -55,7 +55,7 @@ When your simulation has finished, a file of the name ``tutorial_singlerx.sqlite
 will be in your file folder. Your Jupyter Notebook can then be used with 
 `Cymetric <https://fuelcycle.org/user/cymetric/index.html>`_ to analyze your 
 data. Examples of how to use Cymetric can be found in the `GitHub 
-<https://github.com/cyclus/cymetric/tree/master/examples>`_.
+<https://github.com/cyclus/cymetric/tree/main/examples>`_.
 
 
 Backup: Files for Success

diff --git a/doctrees/environment.pickle b/doctrees/environment.pickle
diff --git a/doctrees/kernel/build_from_source.doctree b/doctrees/kernel/build_from_source.doctree
diff --git a/doctrees/kernel/contributing_to_cyclus.doctree b/doctrees/kernel/contributing_to_cyclus.doctree
diff --git a/doctrees/kernel/style_guide.doctree b/doctrees/kernel/style_guide.doctree
diff --git a/doctrees/user/tutorial/run_cyclus_native.doctree b/doctrees/user/tutorial/run_cyclus_native.doctree
diff --git a/kernel/build_from_source.html b/kernel/build_from_source.html
@@ -139,12 +139,12 @@ <h2>Unfamiliar with git and Github?<a class="headerlink" href="#unfamiliar-with-
 <p>Note that each <span style="font-variant:small-caps;">Cyclus</span> repository has <strong>two</strong> branches:</p>
 <blockquote>
 <div><ul class="simple">
-<li><p>master – the latest stable release of the library</p></li>
+<li><p>main – the latest stable release of the library</p></li>
 <li><p>develop – the latest working copy that passes all tests</p></li>
 </ul>
 </div></blockquote>
 <p>The above branches are synchronized with each other, and should be used in tandem
-(i.e., use master (<span style="font-variant:small-caps;">Cyclus</span>) with master (Cycamore) or develop with develop only).</p>
+(i.e., use main (<span style="font-variant:small-caps;">Cyclus</span>) with main (Cycamore) or develop with develop only).</p>
 <section id="help-with-git-and-github">
 <h3>Help with git and GitHub<a class="headerlink" href="#help-with-git-and-github" title="Link to this heading">¶</a></h3>
 <p>If you are unfamiliar with git, here are some resources:</p>

diff --git a/kernel/contributing_to_cyclus.html b/kernel/contributing_to_cyclus.html
@@ -119,7 +119,7 @@ <h2>Working on a Topic<a class="headerlink" href="#working-on-a-topic" title="Li
 <li><p>Your code has been reviewed by another developer.</p></li>
 </ul>
 <p>Code from the “develop” branch generally must pass even more rigorous checks
-before being integrated into the “master” branch. Hotfixes would be a
+before being integrated into the “main” branch. Hotfixes would be a
 possible exception to this.</p>
 </section>
 <section id="keeping-your-fork-up-to-date">
@@ -130,12 +130,12 @@ <h2>Keeping Your Fork Up To Date<a class="headerlink" href="#keeping-your-fork-u
 <li><p>The “develop” branch is how <span style="font-variant:small-caps;">Cyclus</span> developers will share (generally
 compilable) progress when we are not yet ready for the code to become
 ‘production’.</p></li>
-<li><p>Keep your own “master” and “develop” branches in sync with the upstream
-repository’s “master” and “develop” branches. The master branch should
+<li><p>Keep your own “main” and “develop” branches in sync with the upstream
+repository’s “main” and “develop” branches. The main branch should
 always be the ‘stable’ or ‘production’ release of <span style="font-variant:small-caps;">Cyclus</span>.</p>
 <blockquote>
 <div><ul>
-<li><p>Pull the most recent history from the upstream repository “master”
+<li><p>Pull the most recent history from the upstream repository “main”
 and/or “develop” branches before you merge changes into your
 corresponding local branch. Consider doing a rebase pull instead of
 a regular pull or ‘fetch and merge’.  For example:</p>
@@ -148,7 +148,7 @@ <h2>Keeping Your Fork Up To Date<a class="headerlink" href="#keeping-your-fork-u
 </div></blockquote>
 </li>
 <li><p>As you do development on topic branches in your own fork, consider
-rebasing the topic branch onto the “master” and/or “develop”  branches
+rebasing the topic branch onto the “main” and/or “develop”  branches
 after <em>pulls</em> from the upstream repository rather than merging the pulled
 changes into your branch.  This will help maintain a more linear (and clean)
 history.  <em>Please see caution about rebasing below</em>.  For example:</p>
@@ -257,7 +257,7 @@ <h2>Reviewing a Pull Request<a class="headerlink" href="#reviewing-a-pull-reques
 <li><p>Accept the Pull Request</p>
 <ul>
 <li><p>In general, <strong>every commit</strong> (notice this is not ‘every push’) to the
-“develop” and “master” branches should compile and pass tests. This
+“develop” and “main” branches should compile and pass tests. This
 is guaranteed by using a NON-fast-forward merge during the pull request
 acceptance process.</p></li>
 <li><p>The green “Merge Pull Request” button does a non-fast-forward merge by

diff --git a/kernel/style_guide.html b/kernel/style_guide.html
@@ -89,7 +89,7 @@ <h3>Navigation</h3>
 <h1>Style Guidelines for Developers<a class="headerlink" href="#style-guidelines-for-developers" title="Link to this heading">¶</a></h1>
 <p><span style="font-variant:small-caps;">Cyclus</span> uses the <a class="reference external" href="http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml">Google C++ Style Guide</a> and <a class="reference external" href="http://google-styleguide.googlecode.com/svn/trunk/pyguide.html">Google Python Style Guide</a>.
 In order to ensure compliance with these styles, we recommend the <a class="reference external" href="http://astyle.sourceforge.net">Artistic
-Style</a> tool with the following <a class="reference external" href="http://github.com/cyclus/cyclus/blob/master/misc/.astylerc">settings</a> located in <span style="font-variant:small-caps;">Cyclus</span> repo. However,
+Style</a> tool with the following <a class="reference external" href="http://github.com/cyclus/cyclus/blob/main/misc/.astylerc">settings</a> located in <span style="font-variant:small-caps;">Cyclus</span> repo. However,
 be wary of applying this tool blindly because it has some <a class="reference external" href="https://sourceforge.net/p/astyle/bugs/">limits and bugs</a>.
 <a class="reference external" href="http://google-styleguide.googlecode.com/svn/trunk/cpplint/">Cpplint</a> and <a class="reference external" href="http://www.pylint.org/">Pylint</a> are other helpful tools to check your code for style
 and syntax errors. Unfortunately, these tools may also suffer false positives

diff --git a/searchindex.js b/searchindex.js
diff --git a/user/tutorial/run_cyclus_native.html b/user/tutorial/run_cyclus_native.html
@@ -126,7 +126,7 @@ <h2>Jupyter Notebook Scenario Execution<a class="headerlink" href="#jupyter-note
 <p>When your simulation has finished, a file of the name <code class="docutils literal notranslate"><span class="pre">tutorial_singlerx.sqlite</span></code>
 will be in your file folder. Your Jupyter Notebook can then be used with
 <a class="reference external" href="https://fuelcycle.org/user/cymetric/index.html">Cymetric</a> to analyze your
-data. Examples of how to use Cymetric can be found in the <a class="reference external" href="https://github.com/cyclus/cymetric/tree/master/examples">GitHub</a>.</p>
+data. Examples of how to use Cymetric can be found in the <a class="reference external" href="https://github.com/cyclus/cymetric/tree/main/examples">GitHub</a>.</p>
 <section id="backup-files-for-success">
 <h3>Backup: Files for Success<a class="headerlink" href="#backup-files-for-success" title="Link to this heading">¶</a></h3>
 <p>If your run did not succeed, you can retrieve correct input and output files <a class="reference external" href="https://doi.org/10.5281/zenodo.4557613">here</a> under <code class="docutils literal notranslate"><span class="pre">input_oncethrough.xml</span></code>