p15693087
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Updated Git branch "master" to "main". 

This change follows a long discussion on django-develops:

https://groups.google.com/g/django-developers/c/tctDuKUGosc/
This commit is contained in:
Markus Holtermann 2021-02-25 10:52:48 +01:00 committed by Mariusz Felisiak
parent a124365de8
commit d9a266d657
15 changed files with 65 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/conf.py
View File

@ -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', '#'),
}

26
docs/internals/contributing/committing-code.txt
View File

@ -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
<https://code.djangoproject.com/wiki/CommitterTips#AutomatingBackports>`_

2
docs/internals/contributing/localizing.txt
View File

@ -63,7 +63,7 @@ The format files aren't managed by the use of Transifex. To change them, you
must :doc:`create a patch<writing-code/submitting-patches>` 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.

6
docs/internals/contributing/triaging-tickets.txt
View File

@ -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

4
docs/internals/contributing/writing-code/submitting-patches.txt
View File

@ -268,8 +268,8 @@ Bugs
is applied)?
* If it's a bug that :ref:`qualifies for a backport <supported-versions-policy>`
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
------------

4
docs/internals/contributing/writing-code/unit-tests.txt
View File

@ -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
<faq-python-version-support>`, since there are often bugs in earlier versions

10
docs/internals/contributing/writing-code/working-with-git.txt
View File

@ -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

14
docs/internals/git.txt
View File

@ -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.

4
docs/internals/howto-release-django.txt
View File

@ -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

23
docs/internals/release-process.txt
View File

@ -128,10 +128,10 @@ varying levels. See `the supported versions section
<https://www.djangoproject.com/download/#supported-versions>`_ 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.

6
docs/internals/security.txt
View File

@ -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
<security-disclosure>`.
@ -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:

12
docs/intro/contributing.txt
View File

@ -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

6
docs/intro/whatsnext.txt
View File

@ -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 <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

4
docs/ref/contrib/gis/gdal.txt
View File

@ -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
==========================

2
tests/utils_tests/files/strip_tags1.html
View File

@ -374,7 +374,7 @@
</div> <!-- /.select-menu-item -->
<div class="select-menu-item js-navigation-item js-navigation-target ">
<span class="select-menu-item-icon mini-icon mini-icon-confirm"></span>
<a href="/django/django/commit/master" class="js-navigation-open select-menu-item-text js-select-button-text css-truncate-target" data-name="master" rel="nofollow" title="master">master</a>
<a href="/django/django/commit/main" class="js-navigation-open select-menu-item-text js-select-button-text css-truncate-target" data-name="main" rel="nofollow" title="main">main</a>
</div> <!-- /.select-menu-item -->
<div class="select-menu-item js-navigation-item js-navigation-target ">
<span class="select-menu-item-icon mini-icon mini-icon-confirm"></span>