MAINT: Switch the primary branch name to main

Author: bashtage

.github/ISSUE_TEMPLATE/bug_report.md

@@ -23,9 +23,9 @@ assignees: ''
 
 **Note**: As you can see, there are many issues on our GitHub tracker, so it is very possible that your issue has been posted before. Please check first before submitting so that we do not have to handle and close duplicates.
 
-**Note**: Please be sure you are using the latest released version of `statsmodels`, or a recent build of `master`. If your problem has been fixed in an unreleased version, you might be able to use `master` until a new release occurs. 
+**Note**: Please be sure you are using the latest released version of `statsmodels`, or a recent build of `main`. If your problem has been fixed in an unreleased version, you might be able to use `main` until a new release occurs. 
 
-**Note**: If you are using a released version, have you verified that the bug exists in the master branch of this repository? It helps the limited resources if we know problems exist in the current master so that they do not need to check whether the code sample produces a bug in the next release.
+**Note**: If you are using a released version, have you verified that the bug exists in the main branch of this repository? It helps the limited resources if we know problems exist in the current main branch so that they do not need to check whether the code sample produces a bug in the next release.
 
 </details>
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -12,12 +12,12 @@
 * It is essential that you add a test when making code changes. Tests are not 
   needed for doc changes.
 * When adding a new function, test values should usually be verified in another package (e.g., R/SAS/Stata).
-* When fixing a bug, you must add a test that would produce the bug in master and
+* When fixing a bug, you must add a test that would produce the bug in main and
   then show that it is fixed with the new code.
 * New code additions must be well formatted. Changes should pass flake8. If on Linux or OSX, you can
   verify you changes are well formatted by running 
   ```
-  git diff upstream/master -u -- "*.py" | flake8 --diff --isolated
+  git diff upstream/main -u -- "*.py" | flake8 --diff --isolated
   ```
   assuming `flake8` is installed. This command is also available on Windows 
   using the Windows System for Linux once `flake8` is installed in the 

README.rst

@@ -115,7 +115,7 @@ Main Features
 
 How to get it
 =============
-The master branch on GitHub is the most up to date code
+The main branch on GitHub is the most up to date code
 
 https://www.github.com/statsmodels/statsmodels
 
@@ -174,12 +174,12 @@ Bug reports can be submitted to the issue tracker at
 
 https://github.com/statsmodels/statsmodels/issues
 
-.. |Azure CI Build Status| image:: https://dev.azure.com/statsmodels/statsmodels-testing/_apis/build/status/statsmodels.statsmodels?branch=master
-   :target: https://dev.azure.com/statsmodels/statsmodels-testing/_build/latest?definitionId=1&branch=master
-.. |Codecov Coverage| image:: https://codecov.io/gh/statsmodels/statsmodels/branch/master/graph/badge.svg
+.. |Azure CI Build Status| image:: https://dev.azure.com/statsmodels/statsmodels-testing/_apis/build/status/statsmodels.statsmodels?branch=main
+   :target: https://dev.azure.com/statsmodels/statsmodels-testing/_build/latest?definitionId=1&branch=main
+.. |Codecov Coverage| image:: https://codecov.io/gh/statsmodels/statsmodels/branch/main/graph/badge.svg
    :target: https://codecov.io/gh/statsmodels/statsmodels
-.. |Coveralls Coverage| image:: https://coveralls.io/repos/github/statsmodels/statsmodels/badge.svg?branch=master
-   :target: https://coveralls.io/github/statsmodels/statsmodels?branch=master
+.. |Coveralls Coverage| image:: https://coveralls.io/repos/github/statsmodels/statsmodels/badge.svg?branch=main
+   :target: https://coveralls.io/github/statsmodels/statsmodels?branch=main
 .. |PyPI downloads| image:: https://img.shields.io/pypi/dm/statsmodels.svg?label=Pypi%20downloads
    :target: https://pypi.org/project/statsmodels/
 .. |Conda downloads| image:: https://img.shields.io/conda/dn/conda-forge/statsmodels.svg?label=Conda%20downloads
@@ -189,4 +189,4 @@ https://github.com/statsmodels/statsmodels/issues
 .. |Conda Version| image:: https://anaconda.org/conda-forge/statsmodels/badges/version.svg
    :target: https://anaconda.org/conda-forge/statsmodels/
 .. |License| image:: https://img.shields.io/pypi/l/statsmodels.svg
-   :target: https://github.com/statsmodels/statsmodels/blob/master/LICENSE.txt
+   :target: https://github.com/statsmodels/statsmodels/blob/main/LICENSE.txt

azure-pipelines.yml

@@ -1,7 +1,7 @@
 # https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops#passing-parameters
 
 trigger:
-- master
+- main
 
 variables:
   MKL_NUM_THREADS: 1

codecov.yml

@@ -1,5 +1,5 @@
 codecov:
-  branch: master
+  branch: main
   notify:
     require_ci_to_pass: no
     after_n_builds: 1

docs/source/contrasts.rst

@@ -182,7 +182,7 @@ The coefficients taken on by polynomial coding for `k=4` levels are the linear,
 .. ipython:: python
 
    _, bins = np.histogram(hsb2.read, 3)
-   try: # requires numpy master
+   try: # requires numpy main
        readcat = np.digitize(hsb2.read, bins, True)
    except:
        readcat = np.digitize(hsb2.read, bins)

docs/source/dev/dataset_notes.rst

@@ -64,5 +64,5 @@ used.
 **Step 6:** Edit the `datasets/__init__.py` to import the directory.
 
 That's it! The result can be found `here
-<https://github.com/statsmodels/statsmodels/tree/master/statsmodels/datasets/nile>`_
+<https://github.com/statsmodels/statsmodels/tree/main/statsmodels/datasets/nile>`_
 for reference.

docs/source/dev/git_notes.rst

@@ -62,8 +62,8 @@ Create a Branch
 
 All changes to the code should be made in a feature branch. To create a branch, type::
 
-    git checkout master
-    git rebase upstream/master
+    git checkout main
+    git rebase upstream/main
     git checkout -b shiny-new-feature
 
 The first two lines ensure you are starting from an up-to-date version of the upstream
@@ -76,7 +76,7 @@ Doing::
 will give something like::
 
     * shiny-new-feature
-      master
+      main
 
 to indicate that you are now on the `shiny-new-feature` branch.
 
@@ -173,7 +173,7 @@ this by using `compare view
 #. Navigate to your repository on github.
 #. Click on `Branch List`
 #. Click on the `Compare` button for your feature branch, `shiny-new-feature`.
-#. Select the `base` and `compare` branches, if necessary. This will be `master` and
+#. Select the `base` and `compare` branches, if necessary. This will be `main` and
    `shiny-new-feature`, respectively.
 #. From here you will see a nice overview of your changes. If anything is amiss, you can fix it.
 
@@ -189,7 +189,7 @@ Your request will then be reviewed. If you need to go back and make more
 changes, you can make them in your branch and push them to github and the pull
 request will be automatically updated.
 
-One last thing to note. If there has been a lot of work in upstream/master
+One last thing to note. If there has been a lot of work in upstream/main
 since you started your patch, you might want to rebase. However, you can
 probably get away with not rebasing if these changes are unrelated to the work
 you have done in the `shiny-new-feature` branch. If you can avoid it, then
@@ -212,7 +212,7 @@ should be preferred.
 
 A rebase replays commits from one branch on top of another branch to preserve a
 linear history. Recall that your commits were tested against a (possibly) older
-version of master from which you started your branch, so if you rebase, you
+version of main from which you started your branch, so if you rebase, you
 could introduce bugs. However, if you have only a few commits, this might not
 be such a concern. One great place to start learning about rebase is
 :ref:`rebasing without tears <pydagogue:actual-rebase>`.  In particular, `heed
@@ -226,19 +226,19 @@ work, do not rebase!!
 As for merging, **never merge from trunk into your feature branch**. You will,
 however, want to check that your work will merge cleanly into trunk. This will
 help out the reviewers. You can do this in your local repository by merging
-your work into your master (or any branch that tracks remote master) and
+your work into your main branch (or any branch that tracks the remote main branch) and
 :ref:`run-tests`.
 
 Deleting Branches
 ~~~~~~~~~~~~~~~~~
 
 Once your feature branch is accepted into upstream, you might want to get rid
-of it. First you'll want to merge upstream master into your branch. That way
+of it. First you'll want to merge upstream main into your branch. That way
 git will know that it can safely delete your branch::
 
     git fetch upstream
-    git checkout master
-    git merge upstream/master
+    git checkout main
+    git merge upstream/main
 
 Then you can just do::
 

docs/source/dev/index.rst

@@ -51,8 +51,8 @@ greatly helps the job of maintaining and releasing the software a shared effort.
 
   Check that the build output does not have *any* warnings due to your changes.
 - Follow `PEP8 <https://www.python.org/dev/peps/pep-0008/>`_ style guidelines
-  wherever possible. Compare your code to what's in master by running
-  ``git diff upstream/master -u -- "*.py" | flake8 --diff`` prior to submitting.
+  wherever possible. Compare your code to what's in main by running
+  ``git diff upstream/main -u -- "*.py" | flake8 --diff`` prior to submitting.
 - Finally, please add your changes to the release notes. Open the
   ``docs/source/release/versionX.X.rst`` file that has the version number of the
   next release and add your changes to the appropriate section.

docs/source/dev/maintainer_notes.rst

@@ -31,7 +31,7 @@ Rebasing
 If there are only a few commits, you can rebase to keep a linear history::
 
     git fetch upstream-rw
-    git rebase upstream-rw/master
+    git rebase upstream-rw/main
 
 Rebasing will not automatically close the pull request however, if there is one,
 so do not forget to do this.
@@ -46,7 +46,7 @@ may ask yourself, :ref:`ff-no-ff`? See below for more on this choice. Once
 decided you can do::
 
     git fetch upstream-rw
-    git merge --no-ff upstream-rw/master
+    git merge --no-ff upstream-rw/main
 
 Merging will automatically close the pull request on github.
 
@@ -60,11 +60,11 @@ pushing to the repository::
 
 This shows the history in a compact way of the current branch. This::
 
-    git log -p upstream-rw/master..
+    git log -p upstream-rw/main..
 
 shows the log of commits excluding those that can be reached from
-upstream-rw/master, and including those that can be reached from current HEAD.
-That is, those changes unique to this branch versus upstream-rw/master. See
+upstream-rw/main, and including those that can be reached from current HEAD.
+That is, those changes unique to this branch versus upstream-rw/main. See
 :ref:`Pydagogue <pydagogue:git-log-dots>` for more on using dots with log and
 also for using :ref:`dots with diff <pydagogue:git-diff-dots>`.
 
@@ -74,21 +74,21 @@ Push Your Feature Branch
 All the changes look good? You can push your feature branch after
 :ref:`merging` or :ref:`rebasing` by::
 
-    git push upstream-rw shiny-new-feature:master
+    git push upstream-rw shiny-new-feature:main
 
 Cherry-Picking
 ^^^^^^^^^^^^^^
 
 Say you are interested in some commit in another branch, but want to leave the
 other ones for now. You can do this with a cherry-pick. Use `git log --oneline`
 to find the commit that you want to cherry-pick. Say you want commit `dd9ff35`
-from the `shiny-new-feature` branch. You want to apply this commit to master.
+from the `shiny-new-feature` branch. You want to apply this commit to main.
 You simply do::
 
-    git checkout master
+    git checkout main
     git cherry-pick dd9ff35
 
-And that's all. This commit is now applied as a new commit in master.
+And that's all. This commit is now applied as a new commit in main.
 
 .. _ff-no-ff:
 
@@ -109,7 +109,7 @@ The fast-forward merge does not create a merge commit. This means that the
 existence of the feature branch is lost in the history. The fast-forward is the
 default for Git basically because branches are cheap and, therefore, *usually*
 short-lived. If on the other hand, you have a long-lived feature branch or are
-following an iterative workflow on the feature branch (i.e. merge into master,
+following an iterative workflow on the feature branch (i.e. merge into main,
 then go back to feature branch and add more commits), then it makes sense to
 include only the merge in the main branch, rather than all the intermediate
 commits of the feature branch, so you should use::
@@ -123,7 +123,7 @@ You can apply a pull request through `fetch <https://www.kernel.org/pub/software
 and `merge <https://www.kernel.org/pub/software/scm/git/docs/git-merge.html>`__.
 In your local copy of the main repo::
 
-    git checkout master
+    git checkout main
     git remote add contrib-name git://github.com/contrib-name/statsmodels.git
     git fetch contrib-name
     git merge contrib-name/shiny-new-feature
@@ -141,14 +141,14 @@ of::
 in the commit message. Any and all problems need to be taken care of locally
 before doing::
 
-    git push origin master
+    git push origin main
 
 Releasing
 ---------
 
-1. Checkout master::
+1. Checkout main::
 
-    git checkout statsmodels/master
+    git checkout statsmodels/main
 
 2. Clean the working tree with::
 
@@ -166,7 +166,7 @@ Releasing
 
     git tag -a v0.10.0rc1 -m "Version 0.10.0 Release Candidate 1"
 
-   to use the last commit in master.
+   to use the last commit in main.
 
 4. Checkout the tag::
 
@@ -183,8 +183,8 @@ Releasing
     git checkout -b maintenance/0.10.x
 
    Any bug fixes and maintenance commits intended for the next micro release should be made
-   against master as usual, but tagged with the milestone for the micro release it is intended
-   for. Then merge into master as usual. When ready to do the backports, use the file
+   against main as usual, but tagged with the milestone for the micro release it is intended
+   for. Then merge into main as usual. When ready to do the backports, use the file
    ``tools/backport_pr.py`` to identify which PRs need to be backported and to apply them to the
    maintenance branch. The tag for the release should be made in the maintenance branch.
 
@@ -196,9 +196,9 @@ Releasing
 
     twine upload --repository-url https://test.pypi.org/legacy/ dist/*
 
-8. Go back to the master branch, and add an empty commit::
+8. Go back to the main branch, and add an empty commit::
 
-    git checkout statsmodels/master
+    git checkout statsmodels/main
     git commit --allow-empty -m "Start of 0.11.0 development"
     git tag -a v0.11.0.dev0 -m "Start of 0.11.0 development"
 
@@ -261,7 +261,7 @@ Once any patches have been backported to a maintenance branch, the release steps
 
 Commit Comments
 ---------------
-Prefix commit messages in the master branch of the main shared repository with
+Prefix commit messages in the main branch of the main shared repository with
 the following::
 
     ENH: Feature implementation

docs/source/dev/test_notes.rst

@@ -77,7 +77,7 @@ Tests can be run at different levels of granularity:
 
 How To Write A Test
 -------------------
-NumPy provides a good introduction to unit testing with pytest and NumPy extensions `here <https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt>`__. It is worth a read for some more details.
+NumPy provides a good introduction to unit testing with pytest and NumPy extensions `here <https://github.com/numpy/numpy/blob/main/doc/TESTS.rst.txt>`__. It is worth a read for some more details.
 Here, we will document a few conventions we follow that are worth mentioning. Often we want to test
 a whole model at once rather than just one function, for example. The following is a pared down
 version test_discrete.py. In this case, several different models with different options need to be

docs/source/examples/index.rst

@@ -8,7 +8,7 @@ Examples
 This page provides a series of examples, tutorials and recipes to help you get
 started with ``statsmodels``. Each of the examples shown here is made available
 as an IPython Notebook and as a plain python script on the `statsmodels github
-repository <https://github.com/statsmodels/statsmodels/tree/master/examples>`_.
+repository <https://github.com/statsmodels/statsmodels/tree/main/examples>`_.
 
 We also encourage users to submit their own examples, tutorials or cool
 `statsmodels` trick to the `Examples wiki page

docs/source/faq.rst

@@ -64,8 +64,7 @@ could also reset git to a prior version by:
 
     git reset --hard
     git clean -xdf
-    git checkout master
-    python setup.py clean
+    git checkout main
 
 I'd like to contribute. Where do I start?
 -----------------------------------------

docs/source/install.rst

@@ -45,7 +45,7 @@ available `here <https://www.lfd.uci.edu/~gohlke/pythonlibs/#statsmodels>`__.
 Obtaining the Source
 --------------------
 
-We do not release very often but the master branch of our source code is
+We do not release very often but the main branch of our source code is
 usually fine for everyday use. You can get the latest source from our
 `github repository <https://github.com/statsmodels/statsmodels>`__. Or if you
 have git installed:

docs/source/release/version0.10.rst

@@ -10,14 +10,14 @@ Release summary
 statsmodels is using github to store the updated documentation. Two version are available:
 
 * `Stable <https://www.statsmodels.org/stable/>`_, the latest release
-* `Development <https://www.statsmodels.org/devel/>`_, the latest build of the master branch
+* `Development <https://www.statsmodels.org/devel/>`_, the latest build of the main branch
 
 **Warning**
 
 API stability is not guaranteed for new features, although even in
 this case changes will be made in a backwards compatible way if
 possible. The stability of a new feature depends on how much time it
-was already in statsmodels master and how much usage it has already
+was already in statsmodels main and how much usage it has already
 seen.  If there are specific known problems or limitations, then they
 are mentioned in the docstrings.
 
@@ -625,7 +625,7 @@ Thie following Pull Requests were merged since the last release:
 * :pr:`5204`: MAINT: Avoid/Fix FutureWarnings
 * :pr:`5207`: TST: Ensure random numbers are reproducible
 * :pr:`5208`: TST/CLN: Tighten tol to reduce spurious test failure
-* :pr:`5210`: BLD: Ensure master is available when linting
+* :pr:`5210`: BLD: Ensure main is available when linting
 * :pr:`5211`: MAINT: Import instead of copy/pasting utils
 * :pr:`5213`: MAINT: Move misplaced duration results files
 * :pr:`5214`: MAINT: remove example-like file that could never run
@@ -735,7 +735,7 @@ Thie following Pull Requests were merged since the last release:
 * :pr:`5600`: TST: Relax tolerance for OpenBlas issue
 * :pr:`5601`: Update mixed_linear.rst
 * :pr:`5602`: ENH: White spec test (clean commit for PR 4721)
-* :pr:`5604`: MAINT: Update template to encourage master check
+* :pr:`5604`: MAINT: Update template to encourage main check
 * :pr:`5605`: Guofei9987 modify comments proportion confint
 * :pr:`5606`: Mattwigway mice setting with copy warning
 * :pr:`5607`: Jtweeder graphics addgraphics

docs/source/release/version0.11.rst

@@ -10,14 +10,14 @@ Release summary
 statsmodels is using github to store the updated documentation. Two version are available:
 
 - `Stable <https://www.statsmodels.org/>`_, the latest release
-- `Development <https://www.statsmodels.org/devel/>`_, the latest build of the master branch
+- `Development <https://www.statsmodels.org/devel/>`_, the latest build of the main branch
 
 **Warning**
 
 API stability is not guaranteed for new features, although even in
 this case changes will be made in a backwards compatible way if
 possible. The stability of a new feature depends on how much time it
-was already in statsmodels master and how much usage it has already
+was already in statsmodels main and how much usage it has already
 seen.  If there are specific known problems or limitations, then they
 are mentioned in the docstrings.