Update CONTRIBUTING and RELEASE-INSTRUCTIONS to reflect use of Git Fl…

…ow branch naming conventions

CONTRIBUTING.md

@@ -55,16 +55,16 @@ There is no template for this one but make sure to add the `technical` label.
 
 
 ## Release Workflow
-- Maintainer prepares for a new version by creating a Milestone and adding a place for the release in the `CHANGELOG.md` in the `next` branch.
+- Maintainer prepares for a new version by creating a Milestone and adding a place for the release in the `CHANGELOG.md` in the `develop` branch.
 - Issues are assigned to the Milestone. 
-- When you are assigned an issue, create a branch based on the `next` branch named after the issue number and description, something like `1325-fix-some-bug`. Put the PR in the milestone, link to the corresponding issue from the PR and mark issue as "in progress".
-- As time progresses while developing your feature, keep your code up-to-date with changes in the next and (after feature freeze) release/v-feature-number branches. The [Gitflow docs](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) explain this process in greater detail. (Main difference - we call the Git Flow 'dev' branch - in our nomenclature - the 'next'branch.)
+- When you are assigned an issue, create a branch based on the `develop` branch named after the issue number and description, something like `1325-fix-some-bug`. Put the PR in the milestone, link to the corresponding issue from the PR and mark issue as "in progress".
+- As time progresses while developing your feature, keep your code up-to-date with changes in the next and (after feature freeze) release/v-feature-number branches. The [Gitflow docs](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) explain this process in greater detail. 
 
   Git commands to keep your branch in-sync:
   ```shell script
     git fetch origin
     git merge origin/release/v3.x.x # (if currently in feature freeze)
-    git merge origin/next  
+    git merge origin/develop  
   ```
 - When your PR is ready, add notes to the `CHANGELOG.md` file in your branch and request a review.
 - After code review, if code is merged, the Maintainer will tag the next branch with a prerelease tag and mark corresponding issue with "review" tag for QA.

RELEASE-INSTRUCTONS.md

@@ -1,11 +1,11 @@
 
 ## Release a prerelease  
 
-Prereleases are useful for testing some recently merged code into the next branch.
+Prereleases are useful for testing some recently merged code into the develop branch.
 
 0. Go to the New Release Page on github (https://github.com/Tangerine-Community/Tangerine/releases/new). 
-1. Set "Target" to the `next` branch.
-2. Set the "Tag version" to the version of the `next` branch is currently targeting and append `-prelease-` and then the number of the prerelease. For example, if the current stable version is v3.10.0, there is a `release/v3.11.0` branch because of feature freeze, then the `next` branch is targeting `v3.12.0`. If this is the first prerelease for `v3.12.0`, then the "Tag version" would be `v3.12.0-prerelease-1`. The second prerelease would be `v3.12.0-prerelease-2`.
+1. Set "Target" to the `develop` branch.
+2. Set the "Tag version" to the version of the `develop` branch is currently targeting and append `-prelease-` and then the number of the prerelease. For example, if the current stable version is v3.10.0, there is a `release/v3.11.0` branch because of feature freeze, then the `develop` branch is targeting `v3.12.0`. If this is the first prerelease for `v3.12.0`, then the "Tag version" would be `v3.12.0-prerelease-1`. The second prerelease would be `v3.12.0-prerelease-2`.
 3. Leave the "Release title" blank.
 4. Check the "This is a pre-release" checkbox.
 5. Click "Publish release".
@@ -17,7 +17,7 @@ Prereleases are useful for testing some recently merged code into the next branc
 
 After code freeze, a release branch is made and it's time to start creating some releases for QA. These are technically still "prereleases", just a slightly different intent in that we hope they are stable.
 
-0. Merge master into the release branch in case there have been any other releases that have added code to master.
+0. Merge main into the release branch in case there have been any other releases that have added code to main.
 0. Complete an entry in `CHANGELOG.md` for the release.
 0. Go to the New Release Page on github (https://github.com/Tangerine-Community/Tangerine/releases/new). 
 1. Set "Target" to the release branch branch.
@@ -32,8 +32,8 @@ After code freeze, a release branch is made and it's time to start creating some
 
 Once the release candidate (rc) has passed testing, it's time to roll the stable release.
 
-0. Try to merge master into the release branch. If commits are merged, then there may be released code that is missing from the RC that passed QA. Stop this release and tag a new RC for QA. 
-1. Merge release branch into master. Github actions will automatically create a PR and merge master into next.
+0. Try to merge main into the release branch. If commits are merged, then there may be released code that is missing from the RC that passed QA. Stop this release and tag a new RC for QA. 
+1. Merge release branch into main. Github actions will automatically create a PR and merge main into develop.
 2. Checkout the release candidate tag and tag that commit with a stable version. ie. `git checkout v3.15.0-rc-21 && git tag v3.15.0 && git push origin v3.15.0`
 3. Pull the RC image, rename it, and push it. ie. `docker pull tangerine/tangerine:v3.15.0-rc-21 && docker tag tangerine/tangerine:v3.15.0-rc-21 tangerine/tangerine:v3.15.0 && docker push tangerine/tangerine:v3.15.0`
 4. Make release on Github using the same tag pushed up to Github. Link to the appropriate release on ["What's New" page on docs.tangerinecentral.org](https://docs.tangerinecentral.org/whats-new/). Copy the release notes from the CHANGELOG to this release.
@@ -42,8 +42,8 @@ Once the release candidate (rc) has passed testing, it's time to roll the stable
 9. Announce on Teams we have a new release.
 
 ## Hotfixing a past minor release
-When we want to create a release for an existing minor release, we create a hotfix branch. There is a blind spot on the Git Flow documentation where it assumes you would always create a hotfix branch from the master because you would never hotfix older versions of your software. Because we do hotfix past minor/major releases, to create a hotfix branch we branch from the last stable tag on that major/minor version. 
+When we want to create a release for an existing minor release, we create a hotfix branch. There is a blind spot on the Git Flow documentation where it assumes you would always create a hotfix branch from the main because you would never hotfix older versions of your software. Because we do hotfix past minor/major releases, to create a hotfix branch we branch from the last stable tag on that major/minor version. 
 
 1. Create a hotfix branch by checking out the minor version tag and then create the branch. `git checkout v3.18.7; git checkout -b hotfix/v3.18.8;`
 2. Proceed as usual tagging release candidates on the hotfix branch and when the release candidate has passed QA, that release candidate becomes an official release.
-3. Now we need to get these fixes into the current release. If there is currently a release branch for a minor version being worked on, merge this hotfix branch into the release branch and tag another RC for that release. If there is not currently a release branch being worked on, create a new hotfix branch from master and proceed to QA and follow the usual Git Flow workflow.
+3. Now we need to get these fixes into the current release. If there is currently a release branch for a minor version being worked on, merge this hotfix branch into the release branch and tag another RC for that release. If there is not currently a release branch being worked on, create a new hotfix branch from main and proceed to QA and follow the usual Git Flow workflow.