Use current main branch in docs instead of master

.github/workflows/pr-build-workflow.yml

@@ -2,7 +2,7 @@ name: Pull Request build
 
 on:
   pull_request:
-    branches: [ master ]
+    branches: [ main ]
 
 jobs:
   build:

CONTRIBUTING.adoc

@@ -47,7 +47,7 @@ _you should see only 'origin' - which is the fork you created for your own githu
 _you should now see 'upstream' in addition to 'origin' where 'upstream' is the Spring repository from which releases are built_
 6. `git fetch --all`
 7. `git branch -a`
-_you should see branches on origin as well as upstream, including 'master' and 'maint'_
+_you should see branches on origin as well as upstream, including 'main' and 'maint'_
 
 == A Day in the Life of a Contributor
 
@@ -61,37 +61,37 @@ e.g.: `git push origin GH-123`
 * If you want to collaborate with another contributor, have them fork your repository (add it as a remote) and `git fetch <your-username>` to grab your branch.
 Alternatively, they can use `git fetch --all` to sync their local state with all of their remotes.
 * If you grant those collaborator(s) push access to your repository, they can even apply their changes to your branch.
-* When ready for your contribution to be reviewed for potential inclusion in the master branch of the canonical spring-amqp repository (what you know as 'upstream'), issue a pull request to the SpringSource repository (for more detail, see https://help.github.com/articles/using-pull-requests/[Using pull requests]).
-* The project lead may merge your changes into the upstream master branch as-is, he may keep the pull request open yet add a comment about something that should be modified, or he might reject the pull request by closing it.
-* A prerequisite for any pull request is that it will be cleanly merge-able with the upstream master's current state.
+* When ready for your contribution to be reviewed for potential inclusion in the main branch of the canonical spring-amqp repository (what you know as 'upstream'), issue a pull request to the SpringSource repository (for more detail, see https://help.github.com/articles/using-pull-requests/[Using pull requests]).
+* The project lead may merge your changes into the upstream main branch as-is, he may keep the pull request open yet add a comment about something that should be modified, or he might reject the pull request by closing it.
+* A prerequisite for any pull request is that it will be cleanly merge-able with the upstream main's current state.
 **This is the responsibility of any contributor.**
 If your pull request cannot be applied cleanly, the project lead will most likely add a comment requesting that you make it merge-able.
 For a full explanation, see https://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing].
 As stated there: _"> Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain."_
 
 == Keeping your Local Code in Sync
-* As mentioned above, you should always work on topic branches (since 'master' is a moving target). However, you do want to always keep your own 'origin' master branch in synch with the 'upstream' master.
+* As mentioned above, you should always work on topic branches (since 'main' is a moving target). However, you do want to always keep your own 'origin' main branch in synch with the 'upstream' main.
 * Within your local working directory, you can sync up all remotes' branches with: `git fetch --all`
-* While on your own local master branch: `git pull upstream master` (which is the equivalent of fetching upstream/master and merging that into the branch you are in currently)
+* While on your own local main branch: `git pull upstream main` (which is the equivalent of fetching upstream/main and merging that into the branch you are in currently)
 * Now that you're in synch, switch to the topic branch where you plan to work, e.g.: `git checkout -b AMQP-123`
 * When you get to a stopping point: `git commit`
-* If changes have occurred on the upstream/master while you were working you can synch again:
-    - Switch back to master: `git checkout master`
-    - Then: `git pull upstream master`
+* If changes have occurred on the upstream/main while you were working you can synch again:
+    - Switch back to main: `git checkout main`
+    - Then: `git pull upstream main`
     - Switch back to the topic branch: `git checkout AMQP-123` (no -b needed since the branch already exists)
-    - Rebase the topic branch to minimize the distance between it and your recently synched master branch: `git rebase master`
+    - Rebase the topic branch to minimize the distance between it and your recently synched main branch: `git rebase main`
 (Again, for more detail see https://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing]).
-* **Note** While it is generally recommended to __not__ re-write history by using `push --force`, and we do not do this on `master` (and release) branches in the main repo, we require topic branches for pull requests to be rebased before merging, in order to maintain a clean timeline and avoid "merge" commits.
+* **Note** While it is generally recommended to __not__ re-write history by using `push --force`, and we do not do this on `main` (and release) branches in the main repo, we require topic branches for pull requests to be rebased before merging, in order to maintain a clean timeline and avoid "merge" commits.
 * If, while rebasing for the merge, we find significant conflicts, we may ask you to rebase and `push --force` to your topic branch after resolving the conflicts.
-* Assuming your pull request is merged into the 'upstream' master, you will actually end up pulling that change into
-your own master eventually, and at that time, you may decide to delete the topic branch from your local repository and
+* Assuming your pull request is merged into the 'upstream' main, you will actually end up pulling that change into
+your own main eventually, and at that time, you may decide to delete the topic branch from your local repository and
 your fork (origin) if you pushed it there.
     - to delete the local branch: `git branch -d GH-123`
     - to delete the branch from your origin: `git push origin :GH-123`
 
 == Maintain a linear commit history
 
-When merging to master, the project __always__ uses fast-forward merges.
+When merging to main, the project __always__ uses fast-forward merges.
 When issuing pull requests, please ensure that your commit history is linear.
 From the command line you can check this using:
 
@@ -117,7 +117,7 @@ This command, will provide the following output, which in this case shows a nice
 ----
 
 If you see intersecting lines, that usually means that you forgot to rebase you branch.
-As mentioned earlier, **please rebase against master** before issuing a pull request.
+As mentioned earlier, **please rebase against main** before issuing a pull request.
 
 == Mind the whitespace
 

README.md

@@ -1,4 +1,4 @@
-Spring AMQP [<img src="https://build.spring.io/plugins/servlet/wittified/build-status/AMQP-MASTER">](https://build.spring.io/browse/AMQP-MASTER) [![Join the chat at https://gitter.im/spring-projects/spring-amqp](https://badges.gitter.im/spring-projects/spring-amqp.svg)](https://gitter.im/spring-projects/spring-amqp?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
+Spring AMQP [<img src="https://build.spring.io/plugins/servlet/wittified/build-status/AMQP-MAIN">](https://build.spring.io/browse/AAMQP-MAIN) [![Join the chat at https://gitter.im/spring-projects/spring-amqp](https://badges.gitter.im/spring-projects/spring-amqp.svg)](https://gitter.im/spring-projects/spring-amqp?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
 ===========
 
 This project provides support for using Spring and Java with [AMQP 0.9.1](https://www.rabbitmq.com/amqp-0-9-1-reference.html), and in particular [RabbitMQ](https://www.rabbitmq.com/).
@@ -115,7 +115,7 @@ None of these is essential for a pull request, but they will all help.  They can
 * Add yourself as an @author to the .java files that you modify substantially (more than cosmetic changes).
 * Add some Javadocs and, if you change the namespace, some XSD doc elements.
 * A few unit tests would help a lot as well - someone has to do it.
-* If no-one else is using your branch, please rebase it against the current master (or other target branch in the main project).
+* If no-one else is using your branch, please rebase it against the current main (or other target branch in the main project).
 
 # License
 

src/dist/README.md

@@ -114,7 +114,7 @@ None of these is essential for a pull request, but they will all help.  They can
 * Add yourself as an @author to the .java files that you modify substantially (more than cosmetic changes).
 * Add some Javadocs and, if you change the namespace, some XSD doc elements.
 * A few unit tests would help a lot as well - someone has to do it.
-* If no-one else is using your branch, please rebase it against the current master (or other target branch in the main project).
+* If no-one else is using your branch, please rebase it against the current main (or other target branch in the main project).
 
 # License