Change `master` to `main` (#6830)

* Update references to `master` branch to say `main`

* Update external links

* Update links in old release notes
  Use tagged versions of code rather than current code

.circleci/config.yml

@@ -78,4 +78,4 @@ workflows:
             filters:
               branches:
                 only:
-                  - master
+                  - main

.circleci/trigger-nightly-build.sh

@@ -1,9 +1,9 @@
 #!/bin/bash
-# Triggers a nightly build for the latest commit on master
+# Triggers a nightly build for the latest commit on main
 # Use this for testing changes to the nightly release process
 # Call with the CIRCLE_API_USER_TOKEN set to your Personal API key
 # You can find this under User Settings on Circle CI
 
 curl -u ${CIRCLE_API_USER_TOKEN}: \
      -d build_parameters[CIRCLE_JOB]=nightly-build \
-     https://circleci.com/api/v1.1/project/github/wagtail/wagtail/tree/master
+     https://circleci.com/api/v1.1/project/github/wagtail/wagtail/tree/main

README.md

@@ -1,12 +1,12 @@
 <h1 align="center">
-    <img width="343" src="https://cdn.jsdelivr.net/gh/wagtail/wagtail@master/.github/wagtail.svg" alt="Wagtail">
+    <img width="343" src="https://cdn.jsdelivr.net/gh/wagtail/wagtail@main/.github/wagtail.svg" alt="Wagtail">
     <br>
     <br>
 </h1>
 
 Wagtail is an open source content management system built on Django, with a strong community and commercial support. It's focused on user experience, and offers precise control for designers and developers.
 
-![Wagtail screenshot](https://cdn.jsdelivr.net/gh/wagtail/wagtail@master/.github/wagtail-screenshot-with-browser.png)
+![Wagtail screenshot](https://cdn.jsdelivr.net/gh/wagtail/wagtail@main/.github/wagtail-screenshot-with-browser.png)
 
 ### Features
 
@@ -88,7 +88,7 @@ Feature releases of Wagtail are released every three months. Selected releases a
 
 #### Nightly releases
 
-To try out the latest features before a release, we also create builds from master every night. You can find instructions on how to install the latest nightly release at https://releases.wagtail.io/nightly/index.html
+To try out the latest features before a release, we also create builds from `main` every night. You can find instructions on how to install the latest nightly release at https://releases.wagtail.io/nightly/index.html
 
 ### Contributing
 
@@ -99,23 +99,23 @@ You might like to start by reviewing the [contributing guidelines](https://docs.
 We also welcome translations for Wagtail's interface. Translation work should be submitted through [Transifex](https://www.transifex.com/projects/p/wagtail/).
 
 ### License
-[BSD](https://github.com/wagtail/wagtail/blob/master/LICENSE)
+[BSD](https://github.com/wagtail/wagtail/blob/main/LICENSE)
 
 ### Thanks
 
 We thank the following organisations for their services used in Wagtail's development:
 
-[![Browserstack](https://cdn.jsdelivr.net/gh/wagtail/wagtail@master/.github/browserstack-logo.svg)](https://www.browserstack.com/)<br>
+[![Browserstack](https://cdn.jsdelivr.net/gh/wagtail/wagtail@main/.github/browserstack-logo.svg)](https://www.browserstack.com/)<br>
 [BrowserStack](https://www.browserstack.com/) provides the project with free access to their live web-based browser testing tool, and automated Selenium cloud testing.
 
-[![squash.io](https://cdn.jsdelivr.net/gh/wagtail/wagtail@master/.github/squash-logo.svg)](https://www.squash.io/)<br>
+[![squash.io](https://cdn.jsdelivr.net/gh/wagtail/wagtail@main/.github/squash-logo.svg)](https://www.squash.io/)<br>
 [Squash](https://www.squash.io/) provides the project with free test environments for reviewing pull requests.
 
 
 [![Build Status](https://github.com/wagtail/wagtail/workflows/Wagtail%20CI/badge.svg)](https://github.com/wagtail/wagtail/actions)
 [![License](https://img.shields.io/badge/license-BSD-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)
 [![Version](https://img.shields.io/pypi/v/wagtail.svg)](https://pypi.python.org/pypi/wagtail/) 
-[![Coverage](https://codecov.io/github/wagtail/wagtail/coverage.svg?branch=master)](https://codecov.io/github/wagtail/wagtail?branch=master)
+[![Coverage](https://codecov.io/github/wagtail/wagtail/coverage.svg?branch=main)](https://codecov.io/github/wagtail/wagtail?branch=main)
 [![Total alerts](https://img.shields.io/lgtm/alerts/g/wagtail/wagtail.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/wagtail/wagtail/alerts/)
 [![Language grade: Python](https://img.shields.io/lgtm/grade/python/g/wagtail/wagtail.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/wagtail/wagtail/context:python)
 [![Language grade: JavaScript](https://img.shields.io/lgtm/grade/javascript/g/wagtail/wagtail.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/wagtail/wagtail/context:javascript)

client/scss/tools/_functions.breakpoints.scss

@@ -2,7 +2,7 @@
 //
 // Copyright 2011-2018 The Bootstrap Authors
 // Copyright 2011-2018 Twitter, Inc.
-// Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+// Licensed under MIT (https://github.com/twbs/bootstrap/blob/main/LICENSE)
 
 // Name of the next breakpoint, or null for the last breakpoint.
 //

client/scss/tools/_mixins.breakpoints.scss

@@ -2,7 +2,7 @@
 //
 // Copyright 2011-2018 The Bootstrap Authors
 // Copyright 2011-2018 Twitter, Inc.
-// Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+// Licensed under MIT (https://github.com/twbs/bootstrap/blob/main/LICENSE)
 
 
 // Media of at least the minimum breakpoint width. No query for the smallest breakpoint.

docs/README.md

@@ -1,6 +1,6 @@
 # Wagtail docs
 
-These are Sphinx docs, automatically built at https://docs.wagtail.io when the master branch is committed to Github. To build them locally, install Wagtail's development requirements (in the root Wagtail directory):
+These are Sphinx docs, automatically built at https://docs.wagtail.io when the `main` branch is committed to Github. To build them locally, install Wagtail's development requirements (in the root Wagtail directory):
 
     pip install -e .[testing,docs]
 

docs/advanced_topics/embeds.rst

@@ -117,7 +117,7 @@ provider using the oEmbed protocol. Wagtail has a built-in list of providers
 which are all enabled by default. You can find that provider list at the
 following link:
 
-https://github.com/wagtail/wagtail/blob/master/wagtail/embeds/oembed_providers.py
+https://github.com/wagtail/wagtail/blob/main/wagtail/embeds/oembed_providers.py
 
 .. _customising_embed_providers:
 

docs/conf.py

@@ -304,7 +304,7 @@ def setup(app):
     app.add_css_file('css/custom.css')
     app.add_js_file('js/banner.js')
 
-    github_doc_root = 'https://github.com/wagtail/wagtail/tree/master/docs/'
+    github_doc_root = 'https://github.com/wagtail/wagtail/tree/main/docs/'
 
     app.add_config_value('recommonmark_config', {
         'url_resolver': lambda url: github_doc_root + url,

docs/contributing/committing.rst

@@ -16,7 +16,7 @@ Pull requests should not be merged from Github, apart from small documentation f
 which can be merged with the 'Squash and merge' option. Instead, the code should
 be checked out by a committer locally, the changes examined and rebased,
 the ``CHANGELOG.txt`` and release notes updated,
-and finally the code should be pushed to the master branch.
+and finally the code should be pushed to the ``main`` branch.
 This process is covered in more detail below.
 
 Check out the code locally
@@ -33,10 +33,10 @@ A simple way to do this is by adding the following ``git`` alias to your ``~/.gi
 
 Now you can check out pull request number ``xxxx`` by running ``git pr xxxx``.
 
-Rebase on to master
-===================
+Rebase on to ``main``
+=====================
 
-Now that you have the code, you should rebase the commits on to the ``master`` branch.
+Now that you have the code, you should rebase the commits on to the ``main`` branch.
 Rebasing is preferred over merging,
 as merge commits make the commit history harder to read for small changes.
 
@@ -54,13 +54,13 @@ depending on which will be more readable in the commit history.
 
     $ # Get the latest commits from Wagtail
     $ git fetch upstream
-    $ git checkout master
-    $ git merge --ff-only upstream/master
-    $ # Rebase this pull request on to master
+    $ git checkout main
+    $ git merge --ff-only upstream/main
+    $ # Rebase this pull request on to main
     $ git checkout pr/xxxx
-    $ git rebase master
-    $ # Update master to this commit
-    $ git checkout master
+    $ git rebase main
+    $ # Update main to this commit
+    $ git checkout main
     $ git merge --ff-only pr/xxxx
 
 Update ``CHANGELOG.txt`` and release notes
@@ -117,18 +117,18 @@ The commit message should say ``Release notes for #xxxx``:
     $ git add CHANGELOG.txt docs/releases/x.x.x.rst CONTRIBUTORS.rst
     $ git commit -m 'Release notes for #xxxx'
 
-Push to master
-==============
+Push to ``main``
+================
 
-The changes are ready to be pushed to ``master`` now.
+The changes are ready to be pushed to ``main`` now.
 
 .. code-block:: console
 
     $ # Check that everything looks OK
-    $ git log upstream/master..master --oneline
-    $ git push --dry-run upstream master
+    $ git log upstream/main..main --oneline
+    $ git push --dry-run upstream main
     $ # Push the commits!
-    $ git push upstream master
+    $ git push upstream main
     $ git branch -d pr/xxxx
 
 When you have made a mistake

docs/contributing/release_process.rst

@@ -89,10 +89,10 @@ Supported versions
 At any moment in time, Wagtail's developer team will support a set of releases to
 varying levels.
 
-* The current development master will get new features and bug fixes
+* The current development ``main`` will get new features and bug fixes
   requiring non-trivial refactoring.
 
-* Patches applied to the master branch must also be applied to the last feature
+* Patches applied to the ``main`` branch must also be applied to the last feature
   release branch, to be released in the next patch release of that feature
   series, when they fix critical problems:
 
@@ -110,7 +110,7 @@ varying levels.
   release for bugs that would have prevented a release in the first place
   (release blockers).
 
-* Security fixes and data loss bugs will be applied to the current master, the
+* Security fixes and data loss bugs will be applied to the current ``main``, the
   last feature release branch, and any other supported long-term
   support release branches.
 
@@ -123,16 +123,16 @@ varying levels.
 As a concrete example, consider a moment in time halfway between the release of
 Wagtail 1.6 and 1.7. At this point in time:
 
-* Features will be added to ``master``, to be released as Wagtail 1.7.
+* Features will be added to ``main``, to be released as Wagtail 1.7.
 
 * Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and
   released as 1.6.1, 1.6.2, etc.
 
 * Security fixes and bug fixes for data loss issues will be applied to
-  ``master`` and to the ``stable/1.6.x`` and ``stable/1.4.x`` (LTS) branches.
+  ``main`` and to the ``stable/1.6.x`` and ``stable/1.4.x`` (LTS) branches.
   They will trigger the release of ``1.6.1``, ``1.4.8``, etc.
 
-* Documentation fixes will be applied to master, and, if easily backported, to
+* Documentation fixes will be applied to ``main``, and, if easily backported, to
   the latest stable branch, ``1.6.x``.
 
 Supported versions of Django
@@ -187,7 +187,7 @@ get everything on it done.
 At the end of phase two, any unfinished features will be postponed until the
 next release.
 
-At this point, the ``stable/A.B.x`` branch will be forked from ``master``.
+At this point, the ``stable/A.B.x`` branch will be forked from ``main``.
 
 Phase three: bugfixes
 ~~~~~~~~~~~~~~~~~~~~~
@@ -208,7 +208,7 @@ candidate - this ensures that translators have the full period between the relea
 candidate and the final release to bring translations up to date. Translations
 will be re-imported immediately before the final release.
 
-In parallel to this phase, ``master`` can receive new features, to be released
+In parallel to this phase, ``main`` can receive new features, to be released
 in the ``A.B+1`` cycle.
 
 Bug-fix releases
@@ -218,7 +218,7 @@ After a feature release (e.g. A.B), the previous release will go into bugfix
 mode.
 
 The branch for the previous feature release (e.g. ``stable/A.B-1.x``) will
-include bugfixes. Critical bugs fixed on master must *also* be fixed on the
+include bugfixes. Critical bugs fixed on ``main`` must *also* be fixed on the
 bugfix branch; this means that commits need to cleanly separate bug fixes from
-feature additions. The developer who commits a fix to master will be
+feature additions. The developer who commits a fix to ``main`` will be
 responsible for also applying the fix to the current bugfix branch.

docs/contributing/security.md

@@ -20,7 +20,7 @@ Django security issues should be reported directly to the Django Project, follow
 
 At any given time, the Wagtail team provides official security support for several versions of Wagtail:
 
-- The master development branch, hosted on GitHub, which will become the next release of Wagtail, receives security support.
+- The ``main`` development branch, hosted on GitHub, which will become the next release of Wagtail, receives security support.
 - The two most recent Wagtail release series receive security support.
   For example, during the development cycle leading to the release of
   Wagtail 2.6, support will be provided for Wagtail 2.5 and Wagtail 2.4. Upon the release of Wagtail 2.6, Wagtail 2.4's security support will end.

docs/editor_manual/new_pages/inserting_videos.rst

@@ -14,5 +14,5 @@ It is possible to embed media into the body text of a web page by clicking the *
 
 * A placeholder of the media will be inserted into the text area.
 
-The embed button can be used to import media from a number of supported providers, you can see the `full list of supported providers in Wagtail’s source code <https://github.com/wagtail/wagtail/blob/master/wagtail/embeds/oembed_providers.py>`_.
+The embed button can be used to import media from a number of supported providers, you can see the `full list of supported providers in Wagtail’s source code <https://github.com/wagtail/wagtail/blob/main/wagtail/embeds/oembed_providers.py>`_.
 

docs/reference/settings.rst

@@ -31,9 +31,9 @@ When ``WAGTAIL_APPEND_SLASH`` is ``False``, requests to Wagtail pages will be se
 
 .. note::
 
-  If you use the ``False`` setting, keep in mind that serving your pages both with and without slashes may affect search engines' ability to index your site. See `this Google Webmaster Blog post`_ for more details.
+  If you use the ``False`` setting, keep in mind that serving your pages both with and without slashes may affect search engines' ability to index your site. See `this Google Search Central Blog post`_ for more details.
 
-.. _this Google Webmaster Blog post: https://webmasters.googleblog.com/2010/04/to-slash-or-not-to-slash.html
+.. _this Google Search Central Blog post: https://developers.google.com/search/blog/2010/04/to-slash-or-not-to-slash
 
 Search
 ======

docs/releases/0.7.rst

@@ -100,5 +100,5 @@ Update to ``focal_point_key`` field on custom Rendition models
 
 The ``focal_point_key`` field on wagtailimages.Rendition has been changed to ``null=False``, to fix an issue with duplicate renditions being created. If you have defined a custom Rendition model in your project (by extending the ``wagtailimages.AbstractRendition`` class), you will need to apply a migration to make the corresponding change on your custom model. Unfortunately neither South nor Django 1.7's migration system are able to generate this automatically - you will need to customise the migration produced by ``./manage.py schemamigration`` / ``./manage.py makemigrations``, using the wagtailimages migration as a guide:
 
-- https://github.com/wagtail/wagtail/blob/master/wagtail/wagtailimages/south_migrations/0004_auto__chg_field_rendition_focal_point_key.py (for South / Django 1.6)
-- https://github.com/wagtail/wagtail/blob/master/wagtail/wagtailimages/migrations/0004_make_focal_point_key_not_nullable.py (for Django 1.7)
+ - https://github.com/wagtail/wagtail/blob/stable/0.7.x/wagtail/wagtailimages/south_migrations/0004_auto__chg_field_rendition_focal_point_key.py (for South / Django 1.6)
+ - https://github.com/wagtail/wagtail/blob/stable/0.7.x/wagtail/wagtailimages/migrations/0004_make_focal_point_key_not_nullable.py (for Django 1.7)

wagtail/admin/static_src/wagtailadmin/js/vendor/bootstrap-transition.js

@@ -3,7 +3,7 @@
  * http://getbootstrap.com/javascript/#transitions
  * ========================================================================
  * Copyright 2011-2014 Twitter, Inc.
- * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/main/LICENSE)
  * ======================================================================== */