diff --git a/docs/conf.py b/docs/conf.py index 6665b50c8b..bb526d1194 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -108,7 +108,7 @@ extlinks = { 'commit': ('https://github.com/django/django/commit/%s', ''), 'cve': ('https://nvd.nist.gov/vuln/detail/CVE-%s', 'CVE-'), # A file or directory. GitHub redirects from blob to tree if needed. - 'source': ('https://github.com/django/django/blob/master/%s', ''), + 'source': ('https://github.com/django/django/blob/main/%s', ''), 'ticket': ('https://code.djangoproject.com/ticket/%s', '#'), } diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt index 13c139c5c5..580ea02f52 100644 --- a/docs/internals/contributing/committing-code.txt +++ b/docs/internals/contributing/committing-code.txt @@ -41,27 +41,27 @@ Once you're ready: .. console:: - $ # Pull in the latest changes from master. - $ git checkout master - $ git pull upstream master - $ # Rebase the pull request on master. + $ # Pull in the latest changes from main. + $ git checkout main + $ git pull upstream main + $ # Rebase the pull request on main. $ git checkout pr/#### - $ git rebase master - $ git checkout master - $ # Merge the work as "fast-forward" to master to avoid a merge commit. + $ git rebase main + $ git checkout main + $ # Merge the work as "fast-forward" to main to avoid a merge commit. $ # (in practice, you can omit "--ff-only" since you just rebased) $ git merge --ff-only pr/XXXX $ # If you're not sure if you did things correctly, check that only the $ # changes you expect will be pushed to upstream. - $ git push --dry-run upstream master + $ git push --dry-run upstream main $ # Push! - $ git push upstream master + $ git push upstream main $ # Delete the pull request branch. $ git branch -d pr/xxxx -Force push to the branch after rebasing on master but before merging and -pushing to upstream. This allows the commit hashes on master and the branch to -match which automatically closes the pull request. +Force push to the branch after rebasing on main but before merging and pushing +to upstream. This allows the commit hashes on main and the branch to match +which automatically closes the pull request. If a pull request doesn't need to be merged as multiple commits, you can use GitHub's "Squash and merge" button on the website. Edit the commit message as @@ -189,7 +189,7 @@ Django's Git repository: [1.3.x] Fixed #17028 -- Changed diveintopython.org -> diveintopython.net. - Backport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from master. + Backport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from main. There's a `script on the wiki `_ diff --git a/docs/internals/contributing/localizing.txt b/docs/internals/contributing/localizing.txt index 8fb6fa5b08..1ff2a1fc85 100644 --- a/docs/internals/contributing/localizing.txt +++ b/docs/internals/contributing/localizing.txt @@ -63,7 +63,7 @@ The format files aren't managed by the use of Transifex. To change them, you must :doc:`create a patch` against the Django source tree, as for any code change: -* Create a diff against the current Git master branch. +* Create a diff against the current Git main branch. * Open a ticket in Django's ticket system, set its ``Component`` field to ``Translations``, and attach the patch to it. diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt index 950c03e4f4..8341ee0e3c 100644 --- a/docs/internals/contributing/triaging-tickets.txt +++ b/docs/internals/contributing/triaging-tickets.txt @@ -420,9 +420,9 @@ inadvertent side-effect. Here's how you can determine this. Begin by writing a regression test for Django's test suite for the issue. For example, we'll pretend we're debugging a regression in migrations. After you've -written the test and confirmed that it fails on the latest master, put it in a -separate file that you can run standalone. For our example, we'll pretend we -created ``tests/migrations/test_regression.py``, which can be run with:: +written the test and confirmed that it fails on the latest main branch, put it +in a separate file that you can run standalone. For our example, we'll pretend +we created ``tests/migrations/test_regression.py``, which can be run with:: $ ./runtests.py migrations.test_regression diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt index 161f6f8d6f..bf9b1f962b 100644 --- a/docs/internals/contributing/writing-code/submitting-patches.txt +++ b/docs/internals/contributing/writing-code/submitting-patches.txt @@ -268,8 +268,8 @@ Bugs is applied)? * If it's a bug that :ref:`qualifies for a backport ` to the stable version of Django, is there a release note in - ``docs/releases/A.B.C.txt``? Bug fixes that will be applied only to the - master branch don't need a release note. + ``docs/releases/A.B.C.txt``? Bug fixes that will be applied only to the main + branch don't need a release note. New Features ------------ diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt index 373df5ea42..fe1d1060b8 100644 --- a/docs/internals/contributing/writing-code/unit-tests.txt +++ b/docs/internals/contributing/writing-code/unit-tests.txt @@ -377,8 +377,8 @@ in ``tests/auth_tests``. Troubleshooting =============== -Test suite hangs or shows failures on ``master`` branch -------------------------------------------------------- +Test suite hangs or shows failures on ``main`` branch +----------------------------------------------------- Ensure you have the latest point release of a :ref:`supported Python version `, since there are often bugs in earlier versions diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt index 5f1ffb5166..9b8713b476 100644 --- a/docs/internals/contributing/writing-code/working-with-git.txt +++ b/docs/internals/contributing/writing-code/working-with-git.txt @@ -69,9 +69,9 @@ Working on a ticket =================== When working on a ticket, create a new branch for the work, and base that work -on upstream/master:: +on ``upstream/main``:: - git checkout -b ticket_xxxxx upstream/master + git checkout -b ticket_xxxxx upstream/main The -b flag creates a new branch for you locally. Don't hesitate to create new branches even for the smallest things - that's what they are there for. @@ -115,7 +115,7 @@ their clone would become corrupt when you edit commits. There are also "public branches". These are branches other people are supposed to fork, so the history of these branches should never change. Good examples -of public branches are the ``master`` and ``stable/A.B.x`` branches in the +of public branches are the ``main`` and ``stable/A.B.x`` branches in the ``django/django`` repository. When you think your work is ready to be pulled into Django, you should create @@ -200,7 +200,7 @@ do this, use:: git rebase The work is automatically rebased using the branch you forked on, in the -example case using ``upstream/master``. +example case using ``upstream/main``. The rebase command removes all your local commits temporarily, applies the upstream commits, and then applies your local commits again on the work. @@ -255,7 +255,7 @@ One of the ways that developers can contribute to Django is by reviewing patches. Those patches will typically exist as pull requests on GitHub and can be easily integrated into your local repository:: - git checkout -b pull_xxxxx upstream/master + git checkout -b pull_xxxxx upstream/main curl https://github.com/django/django/pull/xxxxx.patch | git am This will create a new branch and then apply the changes from the pull request diff --git a/docs/internals/git.txt b/docs/internals/git.txt index 85f0c667a2..5c2a17e02c 100644 --- a/docs/internals/git.txt +++ b/docs/internals/git.txt @@ -31,7 +31,7 @@ Django releases, which you can browse online. The Git repository includes several `branches`_: -* ``master`` contains the main in-development code which will become +* ``main`` contains the main in-development code which will become the next packaged release of Django. This is where most development activity is focused. @@ -54,12 +54,16 @@ website can be found at `github.com/django/djangoproject.com .. _branches: https://github.com/django/django/branches .. _tags: https://github.com/django/django/tags -The master branch -================= +The main branch +=============== If you'd like to try out the in-development code for the next release of Django, or if you'd like to contribute to Django by fixing bugs or developing -new features, you'll want to get the code from the master branch. +new features, you'll want to get the code from the main branch. + +.. note:: + + Prior to March 2021, the main branch was called ``master``. Note that this will get *all* of Django: in addition to the top-level ``django`` module containing Python code, you'll also get a copy of Django's @@ -142,7 +146,7 @@ Archived feature-development work designed. Feature-development branches tend by their nature to be temporary. Some -produce successful features which are merged back into Django's master to +produce successful features which are merged back into Django's main branch to become part of an official release, but others do not; in either case, there comes a time when the branch is no longer being actively worked on by any developer. At this point the branch is considered closed. diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt index 11ced7d80b..ecd9a752f5 100644 --- a/docs/internals/howto-release-django.txt +++ b/docs/internals/howto-release-django.txt @@ -135,9 +135,9 @@ any time leading up to the actual release: and then commit the changed man page. #. If this is the alpha release of a new series, create a new stable branch - from master. For example, when releasing Django 3.1:: + from main. For example, when releasing Django 3.1:: - $ git checkout -b stable/3.1.x origin/master + $ git checkout -b stable/3.1.x origin/main $ git push origin -u stable/3.1.x:stable/3.1.x #. If this is the "dot zero" release of a new series, create a new branch from diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt index 6091989893..7e899026dc 100644 --- a/docs/internals/release-process.txt +++ b/docs/internals/release-process.txt @@ -128,10 +128,10 @@ varying levels. See `the supported versions section `_ of the download page for the current state of support for each version. -* The current development master will get new features and bug fixes +* The current development branch ``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: @@ -150,8 +150,8 @@ page for the current state of support for each version. 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 - last two feature release branches, and any other supported long-term +* Security fixes and data loss bugs will be applied to the current main branch, + the last two feature release branches, and any other supported long-term support release branches. * Documentation fixes generally will be more freely backported to the last @@ -162,17 +162,18 @@ page for the current state of support for each version. As a concrete example, consider a moment in time halfway between the release of Django 5.1 and 5.2. At this point in time: -* Features will be added to development master, to be released as Django 5.2. +* Features will be added to the development main branch, to be released as + Django 5.2. * Critical bug fixes will be applied to the ``stable/5.1.x`` branch, and released as 5.1.1, 5.1.2, etc. * Security fixes and bug fixes for data loss issues will be applied to - ``master`` and to the ``stable/5.1.x``, ``stable/5.0.x``, and + ``main`` and to the ``stable/5.1.x``, ``stable/5.0.x``, and ``stable/4.2.x`` (LTS) branches. They will trigger the release of ``5.1.1``, ``5.0.5``, ``4.2.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, ``5.1.x``. .. _release-process: @@ -212,7 +213,7 @@ At the end of phase two, any unfinished features will be postponed until the next release. Phase two will culminate with an alpha release. At this point, the -``stable/A.B.x`` branch will be forked from ``master``. +``stable/A.B.x`` branch will be forked from ``main``. Phase three: bugfixes ~~~~~~~~~~~~~~~~~~~~~ @@ -229,7 +230,7 @@ During this phase, committers will be more and more conservative with backports, to avoid introducing regressions. After the release candidate, only release blockers and documentation fixes should be backported. -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 @@ -239,7 +240,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. diff --git a/docs/internals/security.txt b/docs/internals/security.txt index 511c83b537..e394a9a11a 100644 --- a/docs/internals/security.txt +++ b/docs/internals/security.txt @@ -46,9 +46,9 @@ Supported versions At any given time, the Django team provides official security support for several versions of Django: -* The `master development branch`_, hosted on GitHub, which will become the +* The `main development branch`_, hosted on GitHub, which will become the next major release of Django, receives security support. Security issues that - only affect the master development branch and not any stable released versions + only affect the main development branch and not any stable released versions are fixed in public without going through the :ref:`disclosure process `. @@ -67,7 +67,7 @@ comprised solely of *supported* versions of Django: older versions may also be affected, but we do not investigate to determine that, and will not issue patches or new releases for those versions. -.. _master development branch: https://github.com/django/django/ +.. _main development branch: https://github.com/django/django/ .. _security-disclosure: diff --git a/docs/intro/contributing.txt b/docs/intro/contributing.txt index 707fb82920..c61500357f 100644 --- a/docs/intro/contributing.txt +++ b/docs/intro/contributing.txt @@ -243,12 +243,12 @@ to Django's code, the entire test suite **should** pass. If you get failures or errors make sure you've followed all of the previous steps properly. See :ref:`running-unit-tests` for more information. -Note that the latest Django master may not always be stable. When developing -against master, you can check `Django's continuous integration builds`__ to -determine if the failures are specific to your machine or if they are also -present in Django's official builds. If you click to view a particular build, -you can view the "Configuration Matrix" which shows failures broken down by -Python version and database backend. +Note that the latest Django "main" branch may not always be stable. When +developing against "main", you can check `Django's continuous integration +builds`__ to determine if the failures are specific to your machine or if they +are also present in Django's official builds. If you click to view a particular +build, you can view the "Configuration Matrix" which shows failures broken down +by Python version and database backend. __ https://djangoci.com diff --git a/docs/intro/whatsnext.txt b/docs/intro/whatsnext.txt index 578f725ed3..f08ed3b943 100644 --- a/docs/intro/whatsnext.txt +++ b/docs/intro/whatsnext.txt @@ -139,7 +139,7 @@ If you're using an official release of Django, the zipped package (tarball) of the code includes a ``docs/`` directory, which contains all the documentation for that release. -If you're using the development version of Django (aka the master branch), the +If you're using the development version of Django (aka the main branch), the ``docs/`` directory contains all of the documentation. You can update your Git checkout to get the latest changes. @@ -191,7 +191,7 @@ __ https://www.gnu.org/software/make/ Differences between versions ============================ -The text documentation in the master branch of the Git repository contains the +The text documentation in the main branch of the Git repository contains the "latest and greatest" changes and additions. These changes include documentation of new features targeted for Django's next :term:`feature release `. For that reason, it's worth pointing out our policy @@ -200,7 +200,7 @@ to highlight recent changes and additions to Django. We follow this policy: * The development documentation at https://docs.djangoproject.com/en/dev/ is - from the master branch. These docs correspond to the latest feature release, + from the main branch. These docs correspond to the latest feature release, plus whatever features have been added/changed in the framework since then. * As we add features to Django's development version, we update the diff --git a/docs/ref/contrib/gis/gdal.txt b/docs/ref/contrib/gis/gdal.txt index 35abec1168..e3d8b70ced 100644 --- a/docs/ref/contrib/gis/gdal.txt +++ b/docs/ref/contrib/gis/gdal.txt @@ -38,8 +38,8 @@ to have some data to work with. If you're starting out and don't yet have any data of your own to use, GeoDjango tests contain a number of data sets that you can use for testing. You can download them here:: - $ wget https://raw.githubusercontent.com/django/django/master/tests/gis_tests/data/cities/cities.{shp,prj,shx,dbf} - $ wget https://raw.githubusercontent.com/django/django/master/tests/gis_tests/data/rasters/raster.tif + $ wget https://raw.githubusercontent.com/django/django/main/tests/gis_tests/data/cities/cities.{shp,prj,shx,dbf} + $ wget https://raw.githubusercontent.com/django/django/main/tests/gis_tests/data/rasters/raster.tif Vector Data Source Objects ========================== diff --git a/tests/utils_tests/files/strip_tags1.html b/tests/utils_tests/files/strip_tags1.html index 1e09134e81..a533fa90d3 100644 --- a/tests/utils_tests/files/strip_tags1.html +++ b/tests/utils_tests/files/strip_tags1.html @@ -374,7 +374,7 @@
- master + main