rename master to main, aligning with GitHub default

.github/workflows/release-drafter.yml

@@ -4,7 +4,7 @@ on:
   push:
     # branches to consider in the event; optional, defaults to all
     branches:
-      - master
+      - main
 
 jobs:
   update_release_draft:

.travis.yml

@@ -59,7 +59,7 @@ stages:
   - name: docs
   - name: publish
     # Snapshots from Bintray are picked up by a scheduled build on Lightbend's Vegemite
-    if: ((branch = master AND type = push) OR (tag IS present)) AND NOT fork
+    if: ((branch = main AND type = push) OR (tag IS present)) AND NOT fork
 
 notifications:
   webhooks:
@@ -72,5 +72,5 @@ notifications:
 # safelist
 branches:
   only:
-    - master
+    - main
     - /^\d+\.\d+(\.\d+)?(-\S*)?$/

CONTRIBUTING.md

@@ -6,7 +6,7 @@ These guidelines mainly applies to Typesafe’s “mature” projects - not nece
 
 ## General Workflow
 
-This is the process for committing code into master. There are of course exceptions to these rules, for example minor changes to comments and documentation, fixing a broken build etc.
+This is the process for committing code into main. There are of course exceptions to these rules, for example minor changes to comments and documentation, fixing a broken build etc.
 
 1. Make sure you have signed the [Typesafe CLA](http://www.typesafe.com/contribute/cla), if not, sign it online.
 2. Before starting to work on a feature or a fix, you have to make sure that:
@@ -18,7 +18,7 @@ This is the process for committing code into master. There are of course excepti
 4. When the feature or fix is completed you should open a [Pull Request](https://help.github.com/articles/using-pull-requests) on GitHub.
 5. The Pull Request should be reviewed by other maintainers (as many as feasible/practical). Note that the maintainers can consist of outside contributors, both within and outside Typesafe. Outside contributors (for example from EPFL or independent committers) are encouraged to participate in the review process, it is not a closed process.
 6. After the review you should fix the issues as needed (pushing a new commit for new review etc.), iterating until the reviewers give their thumbs up.
-7. Once the code has passed review the Pull Request can be merged into the master branch.
+7. Once the code has passed review the Pull Request can be merged into the main branch.
 
 ## Pull Request Requirements
 
@@ -39,11 +39,11 @@ All Typesafe projects must include Typesafe copyright notices.  Each project can
     - Never delete or change existing copyright notices, just add additional info.
     - Do not use ``@author`` tags since it does not encourage [Collective Code Ownership](http://www.extremeprogramming.org/rules/collective.html). However, each project should make sure that the contributors gets the credit they deserve—in a text file or page on the project website and in the release notes etc.
 
-If these requirements are not met then the code should **not** be merged into master, or even reviewed - regardless of how good or important it is. No exceptions.
+If these requirements are not met then the code should **not** be merged into main, or even reviewed - regardless of how good or important it is. No exceptions.
 
 ## Continuous Integration
 
-Each project should be configured to use a continuous integration (CI) tool (i.e. a build server ala Jenkins). Typesafe has a Jenkins server farm that can be used. The CI tool should, on each push to master, build the **full** distribution and run **all** tests, and if something fails it should email out a notification with the failure report to the committer and the core team. The CI tool should also be used in conjunction with Typesafe’s Pull Request Validator (discussed below).
+Each project should be configured to use a continuous integration (CI) tool (i.e. a build server ala Jenkins). Typesafe has a Jenkins server farm that can be used. The CI tool should, on each push to main, build the **full** distribution and run **all** tests, and if something fails it should email out a notification with the failure report to the committer and the core team. The CI tool should also be used in conjunction with Typesafe’s Pull Request Validator (discussed below).
 
 ## Documentation
 
@@ -79,7 +79,7 @@ Each project must also create and maintain a list of all dependencies and their
 
 ## Work In Progress
 
-It is ok to work on a public feature branch in the GitHub repository. Something that can sometimes be useful for early feedback etc. If so then it is preferable to name the branch accordingly. This can be done by either prefix the name with ``wip-`` as in ‘Work In Progress’, or use hierarchical names like ``wip/..``, ``feature/..`` or ``topic/..``. Either way is fine as long as it is clear that it is work in progress and not ready for merge. This work can temporarily have a lower standard. However, to be merged into master it will have to go through the regular process outlined above, with Pull Request, review etc..
+It is ok to work on a public feature branch in the GitHub repository. Something that can sometimes be useful for early feedback etc. If so then it is preferable to name the branch accordingly. This can be done by either prefix the name with ``wip-`` as in ‘Work In Progress’, or use hierarchical names like ``wip/..``, ``feature/..`` or ``topic/..``. Either way is fine as long as it is clear that it is work in progress and not ready for merge. This work can temporarily have a lower standard. However, to be merged into main it will have to go through the regular process outlined above, with Pull Request, review etc..
 
 Also, to facilitate both well-formed commits and working together, the ``wip`` and ``feature``/``topic`` identifiers also have special meaning.   Any branch labelled with ``wip`` is considered “git-unstable” and may be rebased and have its history rewritten.   Any branch with ``feature``/``topic`` in the name is considered “stable” enough for others to depend on when a group is working on a feature.
 

RELEASING.md

@@ -1,13 +1,13 @@
 # Releasing
 
-This is released from the `master` branch from `1.6.0` forward. Unless an older version needs patching, then it must be released from the maintenance branch, for instance `1.5.x` branch. If there is no maintenance branch for the release that needs patching, create it from the tag.
+This is released from the `main` branch from `1.6.0` forward. Unless an older version needs patching, then it must be released from the maintenance branch, for instance `1.5.x` branch. If there is no maintenance branch for the release that needs patching, create it from the tag.
 
 ## Cutting the release
 
 ### Requires contributor access
 
 - Check the [draft release notes](https://github.com/playframework/twirl/releases) to see if everything is there
-- Wait until [master build finished](https://travis-ci.com/github/playframework/twirl/builds) after merging the last PR
+- Wait until [main build finished](https://travis-ci.com/github/playframework/twirl/builds) after merging the last PR
 - Update the [draft release](https://github.com/playframework/twirl/releases) with the next tag version (eg. `1.6.0`), title and release description
 - Check that Travis CI release build has executed successfully (Travis will start a [CI build](https://travis-ci.com/github/playframework/twirl/builds) for the new tag and publish artifacts to Bintray)
 
@@ -18,4 +18,4 @@ This is released from the `master` branch from `1.6.0` forward. Unless an older
 
 ### Check Maven Central
 
-- The artifacts will become visible at https://repo1.maven.org/maven2/com/typesafe/play/ 
+- The artifacts will become visible at https://repo1.maven.org/maven2/com/typesafe/play/