updated docs to use main and not master

docs/dev/PR.md

@@ -40,13 +40,13 @@ and click on `New pull request`. If templates are available select which one is
 When in doubt merge to `develop`! Otherwise here are some other options:
 
 - merge to another branch if you `checkout` from that branch this helps to break things into smaller parts for quicker review and testing
-- merge to `master` **ONLY** if it is a **HOTFIX** or **RELEASE** branch. 
+- merge to `main` **ONLY** if it is a **HOTFIX** or **RELEASE** branch. 
 
     !!! Note
         **HOTFIX** is a substantial fix for a bug that prevents users from installing or using pyDARN or gives inaccurate data. Document fixes can 
         also be seen as a **HOTFIX** as they do not require release and DOI'ing on the code. 
 
-- In some cases, documentation can be merged to `master` if it is fixing some typos. 
+- In some cases, documentation can be merged to `main` if it is fixing some typos. 
 
 ### Writing a PR
 

docs/dev/branching.md

@@ -35,11 +35,11 @@ In git, "branches" are used to make changes to the code without affecting the ma
 * Update the code
 
         git fetch
-        git pull origin master
+        git pull origin main
 
 * Decide what branch to break off from:
-    * HOTFIX: a fix that needs to be in master ASAP then branch from `master`
-    * Documentation: existing  main documentation with an update then branch from `master`
+    * HOTFIX: a fix that needs to be in main ASAP then branch from `main`
+    * Documentation: existing  main documentation with an update then branch from `main`
     * New Documentation: documentation that doesn't exist in the main documentation then branch from `develop`
     * New code/fix that can wait for a release then branch from `develop`
     * Removing legacy code then branch from `develop`
@@ -48,7 +48,7 @@ In git, "branches" are used to make changes to the code without affecting the ma
         git checkout <branch name>
 
 * Decide on the new branch name. It is recommended to use the following Prefixes:  
-    * HOTFIX/ : a bug that needs to be fixed ASAP and pushed to `master`
+    * HOTFIX/ : a bug that needs to be fixed ASAP and pushed to `main`
     * FIX/ : a bug fix that can wait to be released 
     * EHN/ : an enhancement or new feature to the `develop` code
     * DOC/ : new or updating existing documentation 

docs/dev/releases.md

@@ -63,7 +63,7 @@ and to confirm the version number is correct. State why a release is needed and
         git checkout -b release/<version number>
 
 3. Complete the Pre-Release Checklist below to make some minor changes before opening the pull request
-4. Now create a pull request for the release branch.  This should merge into `master`.
+4. Now create a pull request for the release branch.  This should merge into `main`.
 5. Add the following to the PR info: 
     - **Title**: Release pyDARN <version>
     - **Scope**: add information on the main focus of this release
@@ -99,21 +99,21 @@ and to confirm the version number is correct. State why a release is needed and
 Once the test is complete and at least three approvals are obtained make sure the following steps are performed.  
 The pyDARN lead developer or DAWG chairs should do this step; however, if you request to do it and get approval then go ahead! 
 
-1. **merge** the release branch in `master` and confirm the above updates are there
+1. **merge** the release branch in `main` and confirm the above updates are there
 2. [Tag and release the code](https://github.com/SuperDARN/pydarn/releases/new)
 - tag: v<version number>
-- target: `master`
+- target: `main`
 - Release Title: pyDARN v<version number>
 - Description: Header "Version *number* - Release!" then add "pyDARN release v*number* includes the following features:" listing all the new changes to the code. Please see other [releases](https://github.com/SuperDARN/pydarn/releases) to keep with consistency
 - Hit Publish Release!
 - Once a release has been made check on the [pyDARN Zenodo](https://zenodo.org/record/3727269) and look for the version you just released on the right hand side under **Versions**. Please note this may take some time. If this does not work Contact Lead Developer and DAWG Chairs on the matter.
 - Once the Zenodo DOI is made for the new release, select the DOI markdown tag on the right hand side below **publication date**. Copy the markdown syntax. 
-- `git checkout master` and `git pull origin master`
+- `git checkout main` and `git pull origin main`
 - Paste this syntax in `docs/user/citing.md` under DOI's.       
 
         git add docs/user/citing.md
         git commit -m "updated DOI links"
-        git push origin master
+        git push origin main
 
 - Once this is done, double check everything looks correct
 
@@ -122,9 +122,9 @@ This step requires the lead developers help as they have access to the pyDARN Py
 
 1. Update to make sure everything looks good:
 
-        git checkout master
+        git checkout main
         git fetch
-        git pull origin master 
+        git pull origin main 
 
 2. Remove old builds
 
@@ -169,8 +169,8 @@ After the above is done do the following to make sure everything is up to date:
 
 - Let the DAWG chairs know a pyDARN release has been made to update the DAWG website 
 - Email [DARN-users](darn-users@isee.nagoya-u.ac.jp) about the new release of pyDARN 
-- Merge `master` back into `develop`:
+- Merge `main` back into `develop`:
 
         git checkout develop
         git pull origin develop
-        git merge master
+        git merge main

docs/dev/testing.md

@@ -25,7 +25,7 @@ Every contribution helps!
 
 If you haven't cloned pyDARN before this will get you the correct branch installed to just test:
 `pip install git+https://github.com/superdarn/pydarn@<branchname>`
-Make sure to install any new instances of pyDARN, or branches that are not master in a virtual environment to avoid mixing pyDARN versions! 
+Make sure to install any new instances of pyDARN, or branches that are not main in a virtual environment to avoid mixing pyDARN versions! 
 
 
 If you wish to clone pyDARN for multi-branch comparison or testing in the future: 

docs/user/fan.md

@@ -23,7 +23,7 @@ Currently, fan plots in pyDARN get the geographic positions of a radar's range g
 The mapping of the range gate corners was based on [rbpos in RST](https://github.com/SuperDARN/rst/blob/0aa1fffed4cc48c1eb6372dfc9effa688af95624/codebase/superdarn/src.idl/lib/legacy.1.6/rbposlib.pro).
 
 ### Basic usage
-pyDARN and pyplot need to be imported, as well as any FITACF file needs to be [read in](https://pydarn.readthedocs.io/en/master/user/SDarnRead/):
+pyDARN and pyplot need to be imported, as well as any FITACF file needs to be [read in](https://pydarn.readthedocs.io/en/latest/user/SDarnRead/):
 
 ```python
 import matplotlib.pyplot as plt

docs/user/grid.md

@@ -32,7 +32,7 @@ Currently, grid plots in pyDARN get geomagnetic positions of the gridded data in
 
 ### Basic usage
 
-pyDARN and pyplot need to be imported and the desired GRID file needs to be [read in](https://pydarn.readthedocs.io/en/master/user/SDarnRead/):
+pyDARN and pyplot need to be imported and the desired GRID file needs to be [read in](https://pydarn.readthedocs.io/en/latest/user/SDarnRead/):
 
 ```python
 import matplotlib.pyplot as plt

docs/user/hardware.md

@@ -16,7 +16,7 @@ the additional permissions listed below.
 # Accessing Hardware File Information 
 
 SuperDARN Radar hardware information is stored in hardware files located [here](https://github.com/SuperDARN/hdw). 
-pyDARN pulls down the hardware files from the `master` branch on the [repository](https://github.com/SuperDARN/hdw) to obtain geographical and hardware information for plotting functionality. 
+pyDARN pulls down the hardware files from the `main` branch on the [repository](https://github.com/SuperDARN/hdw) to obtain geographical and hardware information for plotting functionality. 
 
 Users can also read and access these hardware files information by using the function `read_hdw_file`.
 ``` python