kopia lustrzana https://github.com/wagtail/wagtail
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 codepull/6869/head
Naomi I. Morduch Toubman
GitHub
rodzic
54682ea18d
commit
664b0489fe
|
|
@ -78,4 +78,4 @@ workflows:
|
|||
filters:
|
||||
branches:
|
||||
only:
|
||||
- master
|
||||
- main
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
14
README.md
14
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.
|
||||
|
||||
|
||||
|
||||
|
||||
### 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:
|
||||
|
||||
[](https://www.browserstack.com/)<br>
|
||||
[](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.
|
||||
|
||||
[](https://www.squash.io/)<br>
|
||||
[](https://www.squash.io/)<br>
|
||||
[Squash](https://www.squash.io/) provides the project with free test environments for reviewing pull requests.
|
||||
|
||||
|
||||
[](https://github.com/wagtail/wagtail/actions)
|
||||
[](https://opensource.org/licenses/BSD-3-Clause)
|
||||
[](https://pypi.python.org/pypi/wagtail/)
|
||||
[](https://codecov.io/github/wagtail/wagtail?branch=master)
|
||||
[](https://codecov.io/github/wagtail/wagtail?branch=main)
|
||||
[](https://lgtm.com/projects/g/wagtail/wagtail/alerts/)
|
||||
[](https://lgtm.com/projects/g/wagtail/wagtail/context:python)
|
||||
[](https://lgtm.com/projects/g/wagtail/wagtail/context:javascript)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
//
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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>`_.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
======
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
* ======================================================================== */
|
||||
|
||||
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue