MNT: Replace master with main

Revert out-of-scope changes.

Replace some words in narrative.

Apply suggestions from bsipocz

DOC: Remove mentioned of astropy-notebooks

Co-authored-by: Brigitta Sipőcz <[email protected]>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -7,9 +7,9 @@ about: Create a report describing unexpected or incorrect behavior in astropy.
 so you do not need to remove them! -->
 
 <!-- Please be sure to check out our contributing guidelines,
-https://github.com/astropy/astropy/blob/master/CONTRIBUTING.md .
+https://github.com/astropy/astropy/blob/main/CONTRIBUTING.md .
 Please be sure to check out our code of conduct,
-https://github.com/astropy/astropy/blob/master/CODE_OF_CONDUCT.md . -->
+https://github.com/astropy/astropy/blob/main/CODE_OF_CONDUCT.md . -->
 
 <!-- Please have a search on our GitHub repository to see if a similar
 issue has already been posted.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -7,9 +7,9 @@ about: Suggest an idea to improve astropy
 so you do not need to remove them! -->
 
 <!-- Please be sure to check out our contributing guidelines,
-https://github.com/astropy/astropy/blob/master/CONTRIBUTING.md .
+https://github.com/astropy/astropy/blob/main/CONTRIBUTING.md .
 Please be sure to check out our code of conduct,
-https://github.com/astropy/astropy/blob/master/CODE_OF_CONDUCT.md . -->
+https://github.com/astropy/astropy/blob/main/CODE_OF_CONDUCT.md . -->
 
 <!-- Please have a search on our GitHub repository to see if a similar
 issue has already been posted.

.github/PULL_REQUEST_TEMPLATE.md

@@ -2,9 +2,9 @@
 so you do not need to remove them! -->
 
 <!-- Please be sure to check out our contributing guidelines,
-https://github.com/astropy/astropy/blob/master/CONTRIBUTING.md .
+https://github.com/astropy/astropy/blob/main/CONTRIBUTING.md .
 Please be sure to check out our code of conduct,
-https://github.com/astropy/astropy/blob/master/CODE_OF_CONDUCT.md . -->
+https://github.com/astropy/astropy/blob/main/CODE_OF_CONDUCT.md . -->
 
 <!-- If you are new or need to be re-acquainted with Astropy
 contributing workflow, please see

.github/workflows/ci_workflows.yml

@@ -3,7 +3,7 @@ name: CI
 on:
   push:
     branches:
-    - master
+    - main
     tags:
     - '*'
   pull_request:

.github/workflows/open_actions.yml

@@ -27,7 +27,7 @@ jobs:
 
             A project member will respond to you as soon as possible; in
             the meantime, please double-check the [guidelines for submitting
-            issues](https://github.com/astropy/astropy/blob/master/CONTRIBUTING.md#reporting-issues)
+            issues](https://github.com/astropy/astropy/blob/main/CONTRIBUTING.md#reporting-issues)
             and make sure you've provided the requested details.
 
 
@@ -45,7 +45,7 @@ jobs:
 
             A project member will respond to you as soon as possible; in the
             meantime, please have a look over the [Checklist for Contributed
-            Code](https://github.com/astropy/astropy/blob/master/CONTRIBUTING.md#checklist-for-contributed-code)
+            Code](https://github.com/astropy/astropy/blob/main/CONTRIBUTING.md#checklist-for-contributed-code)
             and make sure you've addressed as many of the questions there as
             possible.
 

CITATION

@@ -1 +1 @@
-See https://github.com/astropy/astropy/blob/master/astropy/CITATION
+See https://github.com/astropy/astropy/blob/main/astropy/CITATION

CONTRIBUTING.md

@@ -56,7 +56,7 @@ and follow the Astropy guidelines for reuse, interoperability, and interfacing.
 Each affiliated package has its own developers/maintainers and its own specific
 guidelines for contributions, so be sure to read their docs.
 
-Once you open a pull request (which should be opened against the ``master``
+Once you open a pull request (which should be opened against the ``main``
 branch, not against any of the other branches), please make sure to
 include the following:
 

README.rst

@@ -52,15 +52,15 @@ Astropy is licensed under a 3-clause BSD style license - see the
     :target: https://github.com/astropy/astropy/actions
     :alt: Astropy's GitHub Actions CI Status
 
-.. |CircleCI Status| image::  https://img.shields.io/circleci/build/github/astropy/astropy/master?logo=circleci&label=CircleCI
+.. |CircleCI Status| image::  https://img.shields.io/circleci/build/github/astropy/astropy/main?logo=circleci&label=CircleCI
     :target: https://circleci.com/gh/astropy/astropy
     :alt: Astropy's CircleCI Status
 
-.. |Azure Status| image:: https://dev.azure.com/astropy-project/astropy/_apis/build/status/astropy.astropy?repoName=astropy%2Fastropy&branchName=master
+.. |Azure Status| image:: https://dev.azure.com/astropy-project/astropy/_apis/build/status/astropy.astropy?repoName=astropy%2Fastropy&branchName=main
     :target: https://dev.azure.com/astropy-project/astropy
     :alt: Astropy's Azure Pipelines Status
 
-.. |Coverage Status| image:: https://codecov.io/gh/astropy/astropy/branch/master/graph/badge.svg
+.. |Coverage Status| image:: https://codecov.io/gh/astropy/astropy/branch/main/graph/badge.svg
     :target: https://codecov.io/gh/astropy/astropy
     :alt: Astropy's Coverage Status
 

astropy/config/configuration.py

@@ -483,7 +483,7 @@ def _validate_val(self, val):
         return self._validator.check(self.cfgtype, val)
 
 
-# this dictionary stores the master copy of the ConfigObj's for each
+# this dictionary stores the primary copy of the ConfigObj's for each
 # root package
 _cfgobjs = {}
 

astropy/config/tests/data/astropy.0.3.cfg

@@ -139,7 +139,7 @@ conesearch_dbname = conesearch_good
 
 [vo.validator.validate]
 
-# Cone Search services master list for validation.
+# Cone Search services default list for validation.
 cs_mstr_list = http://vao.stsci.edu/directory/NVORegInt.asmx/VOTCapabilityPredOpt?predicate=1%3D1&capability=conesearch&VOTStyleOption=2
 
 # Only check these Cone Search URLs.

astropy/config/tests/data/astropy.0.3.windows.cfg

@@ -139,7 +139,7 @@ conesearch_dbname = conesearch_good
 
 [vo.validator.validate]
 
-# Cone Search services master list for validation.
+# Cone Search services default list for validation.
 cs_mstr_list = http://vao.stsci.edu/directory/NVORegInt.asmx/VOTCapabilityPredOpt?predicate=1%3D1&capability=conesearch&VOTStyleOption=2
 
 # Only check these Cone Search URLs.

astropy/coordinates/sky_coordinate.py

@@ -760,7 +760,7 @@ def _is_name(self, string):
     def __getattr__(self, attr):
         """
         Overrides getattr to return coordinates that this can be transformed
-        to, based on the alias attr in the master transform graph.
+        to, based on the alias attr in the primary transform graph.
         """
         if '_sky_coord_frame' in self.__dict__:
             if self._is_name(attr):

astropy/coordinates/tests/test_representation.py

@@ -1360,7 +1360,7 @@ def test_represent_as(self):
         for name in REPRESENTATION_CLASSES:
             if name == 'radial':
                 # TODO: Converting a CartesianDifferential to a
-                #       RadialDifferential fails, even on `master`
+                #       RadialDifferential fails, even on `main`
                 continue
             elif name.endswith("geodetic"):
                 # TODO: Geodetic representations do not have differentials yet

astropy/io/ascii/ecsv.py

@@ -241,7 +241,7 @@ class Ecsv(basic.Basic):
     Th ECSV format allows for specification of key table and column meta-data, in
     particular the data type and unit.
 
-    See: https://github.com/astropy/astropy-APEs/blob/master/APE6.rst
+    See: https://github.com/astropy/astropy-APEs/blob/main/APE6.rst
 
     Examples
     --------

azure-pipelines.yml

@@ -10,15 +10,15 @@ resources:
     name: OpenAstronomy/azure-pipelines-templates
     ref: master
 
-# NOTE: for now we only use Azure Pipelines on v* branches, tags, and master
+# NOTE: for now we only use Azure Pipelines on v* branches, tags, and main
 # only on a cron for building the source and wheel distributions. If you want to
 # make changes to this configuration via a pull request, you can *temporarily*
 # change the pr branches include trigger to just '*'
 trigger:
   branches:
     include:
     - 'v*'
-    - master
+    - main
   tags:
     include:
     - 'v*'
@@ -32,7 +32,7 @@ schedules:
     displayName: Daily Build for Nightly Wheels
     branches:
       include:
-        - master
+        - main
     always: true
 
 # Build Linux wheels using manylinux1 for compatibility with old versions
@@ -43,8 +43,8 @@ variables:
   CI: true
 
 jobs:
-# Run this job on non-master branches (when triggered) or if we are on master and on the cron, or if manually triggered through the web ui.
-- ${{ if or(ne(variables['Build.SourceBranchName'], 'master'), eq(variables['Build.Reason'], 'Schedule'), eq(variables['Build.Reason'], 'Manual')) }}:
+# Run this job on non-main branches (when triggered) or if we are on main and on the cron, or if manually triggered through the web ui.
+- ${{ if or(ne(variables['Build.SourceBranchName'], 'main'), eq(variables['Build.Reason'], 'Schedule'), eq(variables['Build.Reason'], 'Manual')) }}:
   - template: publish.yml@OpenAstronomy
     parameters:
 
@@ -59,8 +59,8 @@ jobs:
       ${{ if startsWith(variables['Build.SourceBranch'], 'refs/tags/v') }}:
         pypi_connection_name : 'pypi_endpoint'
 
-      # If the build has run on master then upload the artifacts to the nightly feed
-      ${{ if eq(variables['Build.SourceBranchName'], 'master') }}:
+      # If the build has run on main then upload the artifacts to the nightly feed
+      ${{ if eq(variables['Build.SourceBranchName'], 'main') }}:
         artifact_project : 'astropy'
         artifact_feed : 'nightly'
         remove_local_scheme: true

docs/conf.py

@@ -222,7 +222,7 @@ def minvers(name):
 
 # Setting this URL is requited by sphinx-astropy
 github_issues_url = 'https://github.com/astropy/astropy/issues/'
-edit_on_github_branch = 'master'
+edit_on_github_branch = 'main'
 
 # Enable nitpicky mode - which ensures that all references in the docs
 # resolve.

docs/coordinates/index.rst

@@ -416,7 +416,7 @@ Overview of `astropy.coordinates` Concepts
 .. note ::
     The `~astropy.coordinates` package from v0.4 onward builds from
     previous versions of  the package, and more detailed information and
-    justification of the design is available in `APE (Astropy Proposal for Enhancement) 5 <https://github.com/astropy/astropy- APEs/blob/master/APE5.rst>`_.
+    justification of the design is available in `APE (Astropy Proposal for Enhancement) 5 <https://github.com/astropy/astropy-APEs/blob/main/APE5.rst>`_.
 
 Here we provide an overview of the package and associated framework.
 This background information is not necessary for using `~astropy.coordinates`,

docs/credits.rst

@@ -421,7 +421,7 @@ Other Credits
 
 (If you have contributed to the ``astropy`` core package and your name is missing,
 please send an email to the coordinators, or
-`open a pull request for this page <https://github.com/astropy/astropy/edit/master/docs/credits.rst>`_
+`open a pull request for this page <https://github.com/astropy/astropy/edit/main/docs/credits.rst>`_
 in the `astropy repository <https://github.com/astropy/astropy>`_)
 
 For how to acknowledge Astropy, please see `the Acknowledging or Citing Astropy page <https://www.astropy.org/acknowledging.html>`_.

docs/development/astropy-package-template.rst

@@ -138,10 +138,10 @@ by ``CHANGES.md`` in the instructions.
    instructions. Check that the entry on PyPI is correct, and that
    the tarfile is present.
 
-#. Go back to the master branch and push your changes to github::
+#. Go back to the main branch and push your changes to github::
 
-        git checkout master
-        git push --tags origin master
+        git checkout main
+        git push --tags origin main
 
    Once you have done this, if you use Read the Docs, trigger a ``latest`` build
    then go to the project settings, and under **Versions** you should see the

docs/development/codeguide.rst

@@ -14,7 +14,7 @@ Interface and Dependencies
 
 * All code must be compatible with the versions of Python indicated by the
   ``python_requires`` key in the `setup.cfg
-  <https://github.com/astropy/astropy/blob/master/setup.cfg>`_ file of the
+  <https://github.com/astropy/astropy/blob/main/setup.cfg>`_ file of the
   core package.
 
 * Usage of ``six``, ``__future__``, and ``2to3`` is no longer acceptable.

docs/development/releasing.rst

@@ -189,7 +189,7 @@ Post-Release procedures
    list on the web site if you updated the ``docs/credits.rst`` at the outset.
 
 #. Cherry-pick the commit rendering the changelog and deleting the fragments and
-   open a PR to the astropy *master* branch. Note: updating this when doing the
+   open a PR to the astropy *main* branch. Note: updating this when doing the
    next release with towncrier.
    In the same PR, you also have to update ``docs/whatsnew/index.rst`` and
    ``docs/whatsnew/X.Y.rst`` to link to "what's new" documentation in the
@@ -265,21 +265,21 @@ Performing a Feature Freeze/Branching new Major Versions
 ========================================================
 
 As outlined in
-`APE2 <https://github.com/astropy/astropy-APEs/blob/master/APE2.rst>`_, astropy
+`APE2 <https://github.com/astropy/astropy-APEs/blob/main/APE2.rst>`_, astropy
 releases occur at regular intervals, but feature freezes occur well before the
-actual release.  Feature freezes are also the time when the master branch's
+actual release.  Feature freezes are also the time when the main branch's
 development separates from the new major version's maintenance branch.  This
 allows new development for the next major version to continue while the
 soon-to-be-released version can focus on bug fixes and documentation updates.
 
 The procedure for this is straightforward:
 
-#. Update your local master branch to use to the latest version from github::
+#. Update your local main branch to use to the latest version from github::
 
       $ git fetch upstream --tags
-      $ git checkout -B master upstream/master
+      $ git checkout -B main upstream/main
 
-#. Create a new branch from master at the point you want the feature freeze to
+#. Create a new branch from main at the point you want the feature freeze to
    occur::
 
       $ git branch v<version>.x
@@ -312,7 +312,7 @@ The procedure for this is straightforward:
 #. Push all of these changes up to github::
 
       $ git push upstream v<version>.x:v<version>.x
-      $ git push upstream master:master
+      $ git push upstream main:main
 
    .. note::
 
@@ -343,17 +343,17 @@ that enhance clarity but do not describe new features (e.g., more examples,
 typo fixes, etc).
 
 Bug fix releases are typically managed by maintaining one or more bug fix
-branches separate from the master branch (the release procedure below discusses
+branches separate from the main branch (the release procedure below discusses
 creating these branches).  Typically, whenever an issue is fixed on the Astropy
-master branch a decision must be made whether this is a fix that should be
+main branch a decision must be made whether this is a fix that should be
 included in the Astropy bug fix release.  Usually the answer to this question
 is "yes", though there are some issues that may not apply to the bug fix
 branch.  For example, it is not necessary to backport a fix to a new feature
 that did not exist when the bug fix branch was first created.  New features
 are never merged into the bug fix branch--only bug fixes; hence the name.
 
 In rare cases a bug fix may be made directly into the bug fix branch without
-going into the master branch first.  This may occur if a fix is made to a
+going into the main branch first.  This may occur if a fix is made to a
 feature that has been removed or rewritten in the development version and no
 longer has the issue being fixed.  However, depending on how critical the bug
 is it may be worth including in a bug fix release, as some users can be slow to
@@ -366,31 +366,31 @@ For example, at the time of writing there are two release milestones open:
 v1.2.2 and v0.3.0.  In this case, v1.2.2 is the next bug fix release and all
 issues that should include fixes in that release should be assigned that
 milestone.  Any issues that implement new features would go into the v0.3.0
-milestone--this is any work that goes in the master branch that should not
+milestone--this is any work that goes in the main branch that should not
 be backported.  For a more detailed set of guidelines on using milestones, see
 :ref:`milestones-and-labels`.
 
 
 .. _release-procedure-bug-fix-backport:
 
-Backporting fixes from master
------------------------------
+Backporting fixes from main
+---------------------------
 
 .. note::
 
     The changelog script in ``astropy-procedures`` (``pr_consistency`` scripts
     in particular) does not know about minor releases, thus please be careful.
-    For example, let's say we have two branches (``master`` and ``v1.2.x``).
+    For example, let's say we have two branches (``main`` and ``v1.2.x``).
     Both 1.2.0 and 1.2.1 releases will come out of the same v1.2.x branch.
-    If a PR for 1.2.1 is merged into ``master`` before 1.2.0 is released,
+    If a PR for 1.2.1 is merged into ``main`` before 1.2.0 is released,
     it should not be backported into v1.2.x branch until after 1.2.0 is
     released, despite complaining from the aforementioned script.
     This situation only arises in a very narrow time frame after 1.2.0
     freeze but before its release.
 
 Most fixes are backported using the ``git cherry-pick`` command, which applies
 the diff from a single commit like a patch.  For the sake of example, say the
-current bug fix branch is 'v1.2.x', and that a bug was fixed in master in a
+current bug fix branch is 'v1.2.x', and that a bug was fixed in main in a
 commit ``abcd1234``.  In order to backport the fix, checkout the v1.2.x
 branch (it's also good to make sure it's in sync with the
 `astropy core repository`_) and cherry-pick the appropriate commit::
@@ -408,8 +408,8 @@ sure to backport that as well.
 
 What if the issue required more than one commit to fix?  There are a few
 possibilities for this.  The easiest is if the fix came in the form of a
-pull request that was merged into the master branch.  Whenever GitHub merges
-a pull request it generates a merge commit in the master branch.  This merge
+pull request that was merged into the main branch.  Whenever GitHub merges
+a pull request it generates a merge commit in the main branch.  This merge
 commit represents the *full* difference of all the commits in the pull request
 combined.  What this means is that it is only necessary to cherry-pick the
 merge commit (this requires adding the ``-m 1`` option to the cherry-pick
@@ -457,11 +457,11 @@ there are two choices:
    check out the bug fix branch and commit and push your fix directly.
 
 2. **Preferable**: You may also make a pull request through GitHub against the
-   bug fix branch rather than against master.  Normally when making a pull
+   bug fix branch rather than against main.  Normally when making a pull
    request from a branch on your fork to the `astropy core repository`_, GitHub
-   compares your branch to Astropy's master.  If you look on the left-hand
+   compares your branch to Astropy's main.  If you look on the left-hand
    side of the pull request page, under "base repo: astropy/astropy" there is
-   a drop-down list labeled "base branch: master".  You can click on this
+   a drop-down list labeled "base branch: main".  You can click on this
    drop-down and instead select the bug fix branch ("v1.2.x" for example). Then
    GitHub will instead compare your fix against that branch, and merge into
    that branch when the PR is accepted.
@@ -483,7 +483,7 @@ right version number).
 
 2. The Astropy changelog must be updated to list all issues--especially
    user-visible issues--fixed for the current release.  The changelog should
-   be updated in the master branch, and then merged into the bug fix branch.
+   be updated in the main branch, and then merged into the bug fix branch.
    Most issues *should* already have changelog entries for them. But
    occasionally these are forgotten, so if doesn't exist yet please add one in
    the process of backporting.  See :ref:`changelog-format` for more details.
@@ -504,7 +504,7 @@ The script to actually check consistency should be run like::
     $ python 4.check_consistency.py > consistency.html
 
 Which will generate a simple web page that shows all of the areas where either
-a pull request was merged into master but is *not* in the relevant release that
+a pull request was merged into main but is *not* in the relevant release that
 it has been milestoned for, as well as any changelog irregularities (i.e., PRs
 that are in the wrong section for what the github milestone indicates).  You'll
 want to correct those irregularities *first* before starting the backport