diff --git a/README.md b/README.md index 16d2f7a37c..91c86ed926 100644 --- a/README.md +++ b/README.md @@ -8,8 +8,8 @@ allows users to easily process hundreds or thousands of messages a day. With over 700 contributors merging over 500 commits a month, Zulip is also the largest and fastest growing open source group chat project. -[![GitHub Actions build status](https://github.com/zulip/zulip/actions/workflows/zulip-ci.yml/badge.svg?branch=master)](https://github.com/zulip/zulip/actions/workflows/zulip-ci.yml?query=branch%3Amaster) -[![coverage status](https://img.shields.io/codecov/c/github/zulip/zulip/master.svg)](https://codecov.io/gh/zulip/zulip/branch/master) +[![GitHub Actions build status](https://github.com/zulip/zulip/actions/workflows/zulip-ci.yml/badge.svg)](https://github.com/zulip/zulip/actions/workflows/zulip-ci.yml?query=branch%3Amain) +[![coverage status](https://img.shields.io/codecov/c/github/zulip/zulip/main.svg)](https://codecov.io/gh/zulip/zulip) [![Mypy coverage](https://img.shields.io/badge/mypy-100%25-green.svg)][mypy-coverage] [![code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black) [![code style: prettier](https://img.shields.io/badge/code_style-prettier-ff69b4.svg)](https://github.com/prettier/prettier) @@ -75,6 +75,6 @@ You might be interested in: You may also be interested in reading our [blog](https://blog.zulip.org/) or following us on [Twitter](https://twitter.com/zulip). Zulip is distributed under the -[Apache 2.0](https://github.com/zulip/zulip/blob/master/LICENSE) license. +[Apache 2.0](https://github.com/zulip/zulip/blob/main/LICENSE) license. [beginner-friendly]: https://github.com/zulip/zulip/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 diff --git a/docs/contributing/code-reviewing.md b/docs/contributing/code-reviewing.md index 15129009e1..095d60fbe9 100644 --- a/docs/contributing/code-reviewing.md +++ b/docs/contributing/code-reviewing.md @@ -28,7 +28,7 @@ to dive right into reviewing the PR's core functionality. Once you've received a review and resolved any feedback, it's critical to update the GitHub thread to reflect that. Best practices are to: -* Make sure that CI passes and the PR is rebased onto recent master. +* Make sure that CI passes and the PR is rebased onto recent main. * Post comments on each feedback thread explaining at least how you resolved the feedback, as well as any other useful information (problems encountered, reasoning for why you picked one of several @@ -215,7 +215,7 @@ Some points specific to the Zulip server codebase: To make it easier to review pull requests, if you're working in the Zulip server codebase, use our [git tool] `tools/fetch-rebase-pull-request` to check out a pull request locally -and rebase it against master. +and rebase it against main. If a pull request just needs a little fixing to make it mergeable, feel free to do that in a new commit, then push your branch to GitHub diff --git a/docs/development/setup-vagrant.md b/docs/development/setup-vagrant.md index ac5cf8825c..f0e02c5e58 100644 --- a/docs/development/setup-vagrant.md +++ b/docs/development/setup-vagrant.md @@ -445,7 +445,7 @@ guide][rtd-git-guide]. If after rebasing onto a new version of the Zulip server, you receive new errors while starting the Zulip server or running tests, this is -probably not because Zulip's master branch is broken. Instead, this +probably not because Zulip's main branch is broken. Instead, this is likely because we've recently merged changes to the development environment provisioning process that you need to apply to your development environment. To update your environment, you'll need to diff --git a/docs/development/test-install.md b/docs/development/test-install.md index 8c904f1ca6..91e9cac4fe 100644 --- a/docs/development/test-install.md +++ b/docs/development/test-install.md @@ -6,7 +6,7 @@ configurations; when making changes to more complicated [installation options][installer-docs], Zulip provides tooling to repeatedly test the installation process in a clean environment each time. -[CI]: https://github.com/zulip/zulip/actions/workflows/production-suite.yml?query=branch%3Amaster +[CI]: https://github.com/zulip/zulip/actions/workflows/production-suite.yml?query=branch%3Amain [installer-docs]: ../production/install.md ## Configuring diff --git a/docs/development/using.md b/docs/development/using.md index 431c5a30ac..54e6569630 100644 --- a/docs/development/using.md +++ b/docs/development/using.md @@ -13,9 +13,9 @@ the development environment][authentication-dev-server]. ## Common -* Zulip's master branch moves quickly, and you should rebase +* Zulip's main branch moves quickly, and you should rebase constantly with e.g. `git fetch upstream; git rebase - upstream/master` to avoid developing on an old version of the Zulip + upstream/main` to avoid developing on an old version of the Zulip codebase (leading to unnecessary merge conflicts). * Remember to run `tools/provision` to update your development environment after switching branches; it will run in under a second diff --git a/docs/documentation/integrations.md b/docs/documentation/integrations.md index e6f79ee2db..d0cf4e1c4f 100644 --- a/docs/documentation/integrations.md +++ b/docs/documentation/integrations.md @@ -146,7 +146,7 @@ Here are a few common macros used to document Zulip's integrations: [github-integration]: https://zulip.com/integrations/doc/github [codebase]: https://zulip.com/integrations/doc/codebase [beanstalk]: https://zulip.com/integrations/doc/beanstalk -[integrations-file]: https://github.com/zulip/zulip/blob/master/zerver/lib/integrations.py +[integrations-file]: https://github.com/zulip/zulip/blob/main/zerver/lib/integrations.py ## Writing guidelines diff --git a/docs/documentation/user.md b/docs/documentation/user.md index d021cf3afd..4da8e61f10 100644 --- a/docs/documentation/user.md +++ b/docs/documentation/user.md @@ -252,7 +252,7 @@ The tab identifiers (e.g. `desktop-web` above) and their mappings to the tabs' labels are declared in [zerver/lib/markdown/tabbed_sections.py][tabbed-sections-code]. -[tabbed-sections-code]: https://github.com/zulip/zulip/blob/master/zerver/lib/markdown/tabbed_sections.py +[tabbed-sections-code]: https://github.com/zulip/zulip/blob/main/zerver/lib/markdown/tabbed_sections.py This widget can also be used just to create a nice box around a set of instructions diff --git a/docs/git/cheat-sheet.md b/docs/git/cheat-sheet.md index ba49006d1a..8668ecd3a9 100644 --- a/docs/git/cheat-sheet.md +++ b/docs/git/cheat-sheet.md @@ -8,7 +8,7 @@ See also [fixing commits][fix-commit] - `git add foo.py` - checkout - `git checkout -b new-branch-name` - - `git checkout master` + - `git checkout main` - `git checkout old-branch-name` - commit - `git commit -m "topic: Commit message title."` @@ -36,8 +36,8 @@ See also [fixing commits][fix-commit] - `git push origin +branch-name` - rebase - `git rebase -i HEAD~3` - - `git rebase -i master` - - `git rebase upstream/master` + - `git rebase -i main` + - `git rebase upstream/main` - reflog - `git reflog | head -10` - remote @@ -49,7 +49,7 @@ See also [fixing commits][fix-commit] - show - `git show HEAD` - `git show HEAD~~~` - - `git show master` + - `git show main` - status - `git status` @@ -61,7 +61,7 @@ See also [fixing commits][fix-commit] - `git add -u`: Adds all tracked files to the staging area. - checkout - `git checkout -b new-branch-name`: create branch `new-branch-name` and switch to/check out that new branch - - `git checkout master`: switch to your `master` branch + - `git checkout main`: switch to your `main` branch - `git checkout old-branch-name`: switch to an existing branch `old-branch-name` - commit - `git commit -m "commit message"`: It is recommended to type a @@ -84,7 +84,7 @@ See also [fixing commits][fix-commit] - `git log`: show commit logs - `git log --oneline | head`: To quickly see the latest ten commits on a branch. - pull - - `git pull --rebase`: rebase your changes on top of master. + - `git pull --rebase`: rebase your changes on top of main. - `git pull` (with no options): Will either create a merge commit (which you don't want) or do the same thing as `git pull --rebase`, depending on [whether you've configured Git properly][git-config-clone] @@ -94,8 +94,8 @@ See also [fixing commits][fix-commit] - `git push origin +branch-name`: force push your commits to your origin repository. - rebase - `git rebase -i HEAD~3`: interactive rebasing current branch with first three items on HEAD - - `git rebase -i master`: interactive rebasing current branch with master branch - - `git rebase upstream/master`: rebasing current branch with master branch from upstream repository + - `git rebase -i main`: interactive rebasing current branch with main branch + - `git rebase upstream/main`: rebasing current branch with main branch from upstream repository - reflog - `git reflog | head -10`: manage reference logs for the past 10 commits - remote @@ -107,7 +107,7 @@ See also [fixing commits][fix-commit] - show - `git show HEAD`: display most recent commit - `git show HEAD~~~`: display third most recent commit - - `git show master`: display most recent commit on `master` + - `git show main`: display most recent commit on `main` - status - `git status`: show the working tree status, unstaged and staged files diff --git a/docs/git/pull-requests.md b/docs/git/pull-requests.md index 2c04dfe47a..9a8edd2eb7 100644 --- a/docs/git/pull-requests.md +++ b/docs/git/pull-requests.md @@ -26,7 +26,7 @@ work from being merged before you're confident in it. ## Create a pull request -### Step 0: Make sure you're on a feature branch (not `master`) +### Step 0: Make sure you're on a feature branch (not `main`) It is important to [work on a feature branch](using.html#work-on-a-feature-branch) when creating a pull @@ -35,7 +35,7 @@ branch while it is open, so you will need to reserve your branch only for changes related to your issue, and avoid introducing extraneous changes for other issues or from upstream. -If you are working on a branch named `master`, you need to create and +If you are working on a branch named `main`, you need to create and switch to a feature branch before proceeding. ### Step 1: Update your branch with git rebase @@ -56,9 +56,9 @@ remote: Compressing objects: 100% (23/23), done. remote: Total 69 (delta 49), reused 39 (delta 39), pack-reused 7 Unpacking objects: 100% (69/69), done. From https://github.com/zulip/zulip - 69fa600..43e21f6 master -> upstream/master + 69fa600..43e21f6 main -> upstream/main -$ git rebase upstream/master +$ git rebase upstream/main First, rewinding head to replay your work on top of it... Applying: troubleshooting tip about provisioning diff --git a/docs/git/reviewing.md b/docs/git/reviewing.md index def8033c6b..da5dd0b3e1 100644 --- a/docs/git/reviewing.md +++ b/docs/git/reviewing.md @@ -43,22 +43,22 @@ $ git diff e2f404c 7977169 ## Changes between branches -Display changes between tip of topic branch and tip of master branch: +Display changes between tip of topic branch and tip of main branch: ```console -$ git diff topic master +$ git diff topic main ``` -Display changes that have occurred on master branch since topic branch was created: +Display changes that have occurred on main branch since topic branch was created: ```console -$ git diff topic...master +$ git diff topic...main ``` -Display changes you've committed so far since creating a branch from upstream/master: +Display changes you've committed so far since creating a branch from upstream/main: ```console -$ git diff upstream/master...HEAD +$ git diff upstream/main...HEAD ``` [zulip-rtd-review]: ../contributing/code-reviewing.md diff --git a/docs/git/troubleshooting.md b/docs/git/troubleshooting.md index 99d677724a..1ff17d6af2 100644 --- a/docs/git/troubleshooting.md +++ b/docs/git/troubleshooting.md @@ -27,7 +27,7 @@ You'll know you're creating a merge commit if you're prompted for a commit message and the default is something like this: ```text -Merge branch 'master' of https://github.com/zulip/zulip +Merge branch 'main' of https://github.com/zulip/zulip # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. @@ -44,7 +44,7 @@ Merge: 13bea0e e0c10ed Author: Christie Koehler Date: Mon Oct 10 13:25:51 2016 -0700 - Merge branch 'master' of https://github.com/zulip/zulip + Merge branch 'main' of https://github.com/zulip/zulip ``` Some graphical Git clients may also create merge commits. @@ -55,7 +55,7 @@ to roll back to: ```console $ git reflog -e5f8211 HEAD@{0}: pull upstream master: Merge made by the 'recursive' strategy. +e5f8211 HEAD@{0}: pull upstream main: Merge made by the 'recursive' strategy. 13bea0e HEAD@{1}: commit: test commit for docs. ``` @@ -90,7 +90,7 @@ last commit `13bea0e` before the merge: $ git reflog 13bea0e HEAD@{2}: reset: moving to HEAD@{1} -e5f8211 HEAD@{3}: pull upstream master: Merge made by the 'recursive' strategy. +e5f8211 HEAD@{3}: pull upstream main: Merge made by the 'recursive' strategy. 13bea0e HEAD@{4}: commit: test commit for docs. ``` @@ -115,7 +115,7 @@ For example, let's say you just committed "some work" and your `git log` looks like this: ```console -* 67aea58 (HEAD -> master) some work +* 67aea58 (HEAD -> main) some work * 13bea0e test commit for docs. ``` @@ -126,7 +126,7 @@ $ git reset --hard 13bea0e HEAD is now at 13bea0e test commit for docs. $ git log -* 13bea0e (HEAD -> master) test commit for docs. +* 13bea0e (HEAD -> main) test commit for docs. ``` And then realize you actually needed to keep commit 67aea58. First, use `git @@ -139,7 +139,7 @@ $ git reflog 67aea58 HEAD@{1}: commit: some work $ git cherry-pick 67aea58 - [master 67aea58] some work + [main 67aea58] some work Date: Thu Oct 13 11:51:19 2016 -0700 1 file changed, 1 insertion(+) create mode 100644 test4.txt @@ -153,10 +153,10 @@ which ever branch you are rebasing on top of, is to code that has been changed by those new commits. For example, while I'm working on a file, another contributor makes a change to -that file, submits a pull request and has their code merged into master. +that file, submits a pull request and has their code merged into main. Usually this is not a problem, but in this case the other contributor made a change to a part of the file I also want to change. When I try to bring my -branch up to date with `git fetch` and then `git rebase upstream/master`, I see +branch up to date with `git fetch` and then `git rebase upstream/main`, I see the following: ```console @@ -177,7 +177,7 @@ To check out the original branch and stop rebasing, run "git rebase --abort". ``` This message tells me that Git was not able to apply my changes to README.md -after bringing in the new commits from upstream/master. +after bringing in the new commits from upstream/main. Running `git status` also gives me some information: @@ -205,7 +205,7 @@ Tip: You can see recent changes made to a file by running the following commands: ```bash git fetch upstream -git log -p upstream/master -- /path/to/file +git log -p upstream/main -- /path/to/file ``` You can use this to compare the changes that you have made to a file with the ones in upstream, helping you avoid undoing changes from a previous commit when @@ -265,7 +265,7 @@ to update: $ git checkout Switched to branch '' -$ git merge origin/master +$ git merge origin/main ``` **If you have already made commits on the second computer that you need to diff --git a/docs/git/using.md b/docs/git/using.md index f9b2fc56af..10a4203958 100644 --- a/docs/git/using.md +++ b/docs/git/using.md @@ -20,7 +20,7 @@ branches, with a star next to the current branch: ```console $ git branch * issue-demo - master + main ``` To see even more information about your branches, including remote branches, @@ -29,11 +29,11 @@ use `git branch -vva`: ```console $ git branch -vva * issue-123 517468b troubleshooting tip about provisioning - master f0eaee6 [origin/master] bug: Fix traceback in get_missed_message_token_from_address(). - remotes/origin/HEAD -> origin/master + main f0eaee6 [origin/main] bug: Fix traceback in get_missed_message_token_from_address(). + remotes/origin/HEAD -> origin/main remotes/origin/issue-1234 4aeccb7 Another test commit, with longer message. - remotes/origin/master f0eaee6 bug: Fix traceback in get_missed_message_token_from_address(). - remotes/upstream/master dbeab6a Optimize checks of test database state by moving into Python. + remotes/origin/main f0eaee6 bug: Fix traceback in get_missed_message_token_from_address(). + remotes/upstream/main dbeab6a Optimize checks of test database state by moving into Python. ``` You can also configure [Bash][gitbook-other-envs-bash] and @@ -57,37 +57,37 @@ configured in the step above: $ git fetch upstream ``` -Next, check out your `master` branch and [rebase][gitbook-git-rebase] it on top -of `upstream/master`: +Next, check out your `main` branch and [rebase][gitbook-git-rebase] it on top +of `upstream/main`: ```console -$ git checkout master -Switched to branch 'master' +$ git checkout main +Switched to branch 'main' -$ git rebase upstream/master +$ git rebase upstream/main ``` -This will rollback any changes you've made to master, update it from -`upstream/master`, and then re-apply your changes. Rebasing keeps the commit +This will rollback any changes you've made to main, update it from +`upstream/main`, and then re-apply your changes. Rebasing keeps the commit history clean and readable. When you're ready, [push your changes][github-help-push] to your remote fork. -Make sure you're in branch `master` and then run `git push`: +Make sure you're in branch `main` and then run `git push`: ```console -$ git checkout master -$ git push origin master +$ git checkout main +$ git push origin main ``` You can keep any branch up to date using this method. If you're working on a feature branch (see next section), which we recommend, you would change the -command slightly, using the name of your `feature-branch` rather than `master`: +command slightly, using the name of your `feature-branch` rather than `main`: ```console $ git checkout feature-branch Switched to branch 'feature-branch' -$ git rebase upstream/master +$ git rebase upstream/main $ git push origin feature-branch ``` @@ -99,25 +99,25 @@ feature. Recall from [how Git is different][how-git-is-different] that **Git is designed for lightweight branching and merging.** You can and should create as many branches as you'd like. -First, make sure your master branch is up-to-date with Zulip upstream ([see +First, make sure your main branch is up-to-date with Zulip upstream ([see how][zulip-git-guide-up-to-date]). -Next, from your master branch, create a new tracking branch, providing a +Next, from your main branch, create a new tracking branch, providing a descriptive name for your feature branch: ```console -$ git checkout master -Switched to branch 'master' +$ git checkout main +Switched to branch 'main' $ git checkout -b issue-1755-fail2ban Switched to a new branch 'issue-1755-fail2ban' ``` Alternatively, you can create a new branch explicitly based off -`upstream/master`: +`upstream/main`: ```console -$ git checkout -b issue-1755-fail2ban upstream/master +$ git checkout -b issue-1755-fail2ban upstream/main Switched to a new branch 'issue-1755-fail2ban' ``` @@ -317,7 +317,7 @@ testing in a more production-like environment. The final paragraph indicates that this commit addresses and fixes issue #1755. When you submit your pull request, GitHub will detect and link this reference -to the appropriate issue. Once your commit is merged into zulip/master, GitHub +to the appropriate issue. Once your commit is merged into zulip/main, GitHub will automatically close the referenced issue. See [Closing issues via commit messages][github-help-closing-issues] for details. @@ -335,7 +335,7 @@ This ensures your work is backed up should something happen to your local machine and allows others to follow your progress. It also allows you to [work from multiple computers][self-multiple-computers] without losing work. -Pushing to a feature branch is just like pushing to master: +Pushing to a feature branch is just like pushing to main: ```console $ git push origin @@ -376,7 +376,7 @@ $ git log --all --graph --oneline --decorate * 985116b docs: Add graphic client recs to Git Guide. * 3c40103 docs: Add stubs for remaining Git Guide sections. * fc2c01e docs: Add git guide quickstart. -| * f0eaee6 (upstream/master) bug: Fix traceback in get_missed_message_token_from_address(). +| * f0eaee6 (upstream/main) bug: Fix traceback in get_missed_message_token_from_address(). ``` Alternatively, use your graphical client to view the history for your feature branch. diff --git a/docs/git/working-copies.md b/docs/git/working-copies.md index 2e55afced3..8cbd0d458b 100644 --- a/docs/git/working-copies.md +++ b/docs/git/working-copies.md @@ -31,7 +31,7 @@ Sometimes you want to publish commits. Here are some scenarios: Finally, the Zulip core team will occasionally want your changes! - The Zulip core team can accept your changes and add them to - the official repo, usually on the master branch. + the official repo, usually on the main branch. ## Relevant Git commands diff --git a/docs/git/zulip-tools.md b/docs/git/zulip-tools.md index dcf6ca58c6..becd08f84f 100644 --- a/docs/git/zulip-tools.md +++ b/docs/git/zulip-tools.md @@ -44,13 +44,13 @@ checkout. current branch using `git reset --hard`. Use with caution.** First, make sure you are working in a branch you want to move (in this -example, we'll use the local `master` branch). Then run the script +example, we'll use the local `main` branch). Then run the script with the ID number of the pull request as the first argument. ```console -$ git checkout master -Switched to branch 'master' -Your branch is up-to-date with 'origin/master'. +$ git checkout main +Switched to branch 'main' +Your branch is up-to-date with 'origin/main'. $ ./tools/reset-to-pull-request 1900 + request_id=1900 @@ -70,7 +70,7 @@ HEAD is now at 2bcd1d8 troubleshooting tip about provisioning `tools/fetch-rebase-pull-request` is a short-cut for [checking out a pull request locally][zulip-git-guide-fetch-pr] in its own branch and then updating it with any -changes from upstream/master with `git rebase`. +changes from upstream/main with `git rebase`. Run the script with the ID number of the pull request as the first argument. @@ -84,8 +84,8 @@ remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (4/4), done. From https://github.com/zulip/zulip * branch refs/pull/1913/head -> FETCH_HEAD -+ git checkout upstream/master -b review-1913 -Branch review-1913 set up to track remote branch master from upstream. ++ git checkout upstream/main -b review-1913 +Branch review-1913 set up to track remote branch main from upstream. Switched to a new branch 'review-1913' + git reset --hard FETCH_HEAD HEAD is now at 99aa2bf Add provision.py fails issue in common errors @@ -96,7 +96,7 @@ Current branch review-1913 is up to date. ## Fetch a pull request without rebasing `tools/fetch-pull-request` is a similar to `tools/fetch-rebase-pull-request`, but -it does not rebase the pull request against upstream/master, thereby getting +it does not rebase the pull request against upstream/main, thereby getting exactly the same repository state as the commit author had. Run the script with the ID number of the pull request as the first argument. @@ -146,11 +146,11 @@ achieve this by granting other users permission to write to your fork. `tools/clean-branches` is a shell script that removes branches that are either: -1. Local branches that are ancestors of origin/master. -2. Branches in origin that are ancestors of origin/master and named like `$USER-*`. +1. Local branches that are ancestors of origin/main. +2. Branches in origin that are ancestors of origin/main and named like `$USER-*`. 3. Review branches created by `tools/fetch-rebase-pull-request` and `tools/fetch-pull-request`. -First, make sure you are working in branch `master`. Then run the script without any +First, make sure you are working in branch `main`. Then run the script without any arguments for default behavior. Since removing review branches can inadvertently remove any feature branches whose names are like `review-*`, it is not done by default. To use it, run `tools/clean-branches --reviews`. @@ -164,11 +164,11 @@ Deleting local branch review-original-5156 (was 5a1e982) If there is a merge conflict on yarn.lock, yarn should be run to regenerate the file. *Important* don't delete the yarn.lock file. Check out the -latest one from origin/master so that yarn knows the previous asset versions. +latest one from origin/main so that yarn knows the previous asset versions. Run the following commands ```bash -git checkout origin/master -- yarn.lock +git checkout origin/main -- yarn.lock yarn install git add yarn.lock git rebase --continue diff --git a/docs/overview/changelog.md b/docs/overview/changelog.md index 0d879e58f4..d43a0e03f8 100644 --- a/docs/overview/changelog.md +++ b/docs/overview/changelog.md @@ -470,7 +470,7 @@ log][commit-log] for an up-to-date list of raw changes. was actually an integration for canarytokens.org). - Reformatted the frontend codebase using prettier. This change was included in this maintenance release to ensure backporting patches - from master remains easy. + from main remains easy. ### 3.0 -- July 16, 2020 @@ -2315,5 +2315,5 @@ easily read them all when upgrading across multiple releases. * [Upgrade notes for 1.7.0](#upgrade-notes-for-1-7-0) [docker-zulip]: https://github.com/zulip/docker-zulip -[commit-log]: https://github.com/zulip/zulip/commits/master +[commit-log]: https://github.com/zulip/zulip/commits/main [latest-changelog]: https://zulip.readthedocs.io/en/latest/overview/changelog.html diff --git a/docs/overview/release-lifecycle.md b/docs/overview/release-lifecycle.md index 45a5a50d2b..194a5f5877 100644 --- a/docs/overview/release-lifecycle.md +++ b/docs/overview/release-lifecycle.md @@ -60,25 +60,25 @@ the Zulip server itself (E.g. `https://zulip.example.com/help/`). Many Zulip servers run versions from Git that have not been published in a stable release. -* [Zulip Cloud](https://zulip.com) essentially runs the master - branch. It is usually a few days behind master (with some +* [Zulip Cloud](https://zulip.com) essentially runs the main + branch. It is usually a few days behind main (with some cherry-picked bug fixes), but can fall up to 2 weeks behind when major UI or internals changes mean we'd like to bake changes longer on chat.zulip.org before exposing them to the full Zulip Cloud userbase. * [chat.zulip.org][chat-zulip-org], the bleeding-edge server for the - Zulip development community, is upgraded to master several times - every week. We also often "test deploy" changes not yet in master + Zulip development community, is upgraded to main several times + every week. We also often "test deploy" changes not yet in main to chat.zulip.org to facilitate design feedback. * We maintain Git branches with names like `4.x` containing backported - commits from master that we plan to include in the next maintenance + commits from main that we plan to include in the next maintenance release. Self hosters can [upgrade][upgrade-from-git] to these stable release branches to get bug fixes staged for the next stable release (which is very useful when you reported a bug whose fix we choose to backport). We support these branches as though they were a stable release. * Self-hosters who want new features not yet present in a major - release can [upgrade to master][upgrading-to-master] or run [a fork + release can [upgrade to main][upgrading-to-main] or run [a fork of Zulip][fork-zulip]. ### Compatibility and upgrading @@ -117,7 +117,7 @@ bug fix release, transparently documenting the issue(s) using the industry-standard [CVE advisory process](https://cve.mitre.org/). When new security releases are published, we simultaneously publish -the fixes to the `master` and stable release branches (E.g. `4.x`), so +the fixes to the `main` and stable release branches (E.g. `4.x`), so that anyone using those branches can immediately upgrade as well. See also our [security model][security-model] documentation. @@ -227,7 +227,7 @@ core community, like the Python and JavaScript bindings, are released independently as needed. [electron]: https://www.electronjs.org/ -[upgrading-to-master]: ../production/upgrade-or-modify.html#upgrading-to-master +[upgrading-to-main]: ../production/upgrade-or-modify.html#upgrading-to-main [os-upgrade]: ../production/upgrade-or-modify.html#upgrading-the-operating-system [chat-zulip-org]: https://zulip.com/developer-community/ [fork-zulip]: ../production/upgrade-or-modify.html#modifying-zulip diff --git a/docs/production/authentication-methods.md b/docs/production/authentication-methods.md index a8b8a67e11..e3201251d4 100644 --- a/docs/production/authentication-methods.md +++ b/docs/production/authentication-methods.md @@ -256,7 +256,7 @@ You can look at the [full list of fields][models-py] in the Zulip user model; search for `class UserProfile`, but the above should cover all the fields that would be useful to sync from your LDAP databases. -[models-py]: https://github.com/zulip/zulip/blob/master/zerver/models.py +[models-py]: https://github.com/zulip/zulip/blob/main/zerver/models.py [django-auth-booleans]: https://django-auth-ldap.readthedocs.io/en/latest/users.html#easy-attributes ### Multiple LDAP searches diff --git a/docs/production/deployment.md b/docs/production/deployment.md index e2ed7d37cd..4ed34443c8 100644 --- a/docs/production/deployment.md +++ b/docs/production/deployment.md @@ -21,19 +21,19 @@ and then [continue the normal installation instructions](../production/install.html#step-2-install-zulip). You can also [upgrade Zulip from Git](../production/upgrade-or-modify.html#upgrading-from-a-git-repository). -The most common use case for this is upgrading to `master` to get a +The most common use case for this is upgrading to `main` to get a feature that hasn't made it into an official release yet (often support for a new base OS release). See [upgrading to -master][upgrade-to-master] for notes on how `master` works and the +main][upgrade-to-main] for notes on how `main` works and the support story for it, and [upgrading to future releases][upgrade-to-future-release] for notes on upgrading Zulip afterwards. In particular, we are always very glad to investigate problems with -installing Zulip from `master`; they are rare and help us ensure that +installing Zulip from `main`; they are rare and help us ensure that our next major release has a reliable install experience. -[upgrade-to-master]: ../production/upgrade-or-modify.html#upgrading-to-master +[upgrade-to-main]: ../production/upgrade-or-modify.html#upgrading-to-main [upgrade-to-future-release]: ../production/upgrade-or-modify.html#upgrading-to-future-releases ## Zulip in Docker @@ -345,9 +345,9 @@ Don't forget to update `server_name`, `ssl_certificate`, `ssl_certificate_key` and `proxy_pass` with the appropriate values for your installation. -[nginx-proxy-longpolling-config]: https://github.com/zulip/zulip/blob/master/puppet/zulip/files/nginx/zulip-include-common/proxy_longpolling -[standalone.pp]: https://github.com/zulip/zulip/blob/master/puppet/zulip/manifests/profile/standalone.pp -[zulipchat-puppet]: https://github.com/zulip/zulip/tree/master/puppet/zulip_ops/manifests +[nginx-proxy-longpolling-config]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-common/proxy_longpolling +[standalone.pp]: https://github.com/zulip/zulip/blob/main/puppet/zulip/manifests/profile/standalone.pp +[zulipchat-puppet]: https://github.com/zulip/zulip/tree/main/puppet/zulip_ops/manifests ### Apache2 configuration diff --git a/docs/production/export-and-import.md b/docs/production/export-and-import.md index 9e38911bf3..f2a479d4c7 100644 --- a/docs/production/export-and-import.md +++ b/docs/production/export-and-import.md @@ -304,11 +304,11 @@ archive of all the organization's uploaded files. version of Zulip as the server you're exporting from. * For exports from Zulip Cloud (zulip.com), you need to [upgrade to - master][upgrade-zulip-from-git], since we run run master on + main][upgrade-zulip-from-git], since we run run main on Zulip Cloud: ```bash - /home/zulip/deployments/current/scripts/upgrade-zulip-from-git master + /home/zulip/deployments/current/scripts/upgrade-zulip-from-git main ``` It is not sufficient to be on the latest stable release, as diff --git a/docs/production/install-existing-server.md b/docs/production/install-existing-server.md index b3cd7b0969..deb18c15fb 100644 --- a/docs/production/install-existing-server.md +++ b/docs/production/install-existing-server.md @@ -29,7 +29,7 @@ one created by Zulip into it: ```bash sudo cp /etc/nginx/nginx.conf /etc/nginx.conf.before-zulip-install sudo curl -fL -o /etc/nginx/nginx.conf.zulip \ - https://raw.githubusercontent.com/zulip/zulip/master/puppet/zulip/templates/nginx.conf.template.erb + https://raw.githubusercontent.com/zulip/zulip/main/puppet/zulip/templates/nginx.conf.template.erb sudo meld /etc/nginx/nginx.conf /etc/nginx/nginx.conf.zulip # be sure to merge to the right ``` diff --git a/docs/production/requirements.md b/docs/production/requirements.md index 1c2884cc2b..665dcde7d1 100644 --- a/docs/production/requirements.md +++ b/docs/production/requirements.md @@ -99,7 +99,7 @@ on hardware requirements for larger organizations. [SSRF]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery [smokescreen-proxy]: ../production/deployment.html#using-an-outgoing-http-proxy [reverse-proxy]: ../production/deployment.html#putting-the-zulip-application-behind-a-reverse-proxy -[email-mirror-code]: https://github.com/zulip/zulip/blob/master/zerver/management/commands/email_mirror.py +[email-mirror-code]: https://github.com/zulip/zulip/blob/main/zerver/management/commands/email_mirror.py ## Credentials needed diff --git a/docs/production/settings.md b/docs/production/settings.md index cf18c8e656..163d137b13 100644 --- a/docs/production/settings.md +++ b/docs/production/settings.md @@ -28,7 +28,7 @@ comment documentation for new configuration settings after upgrading to each new major release. [update-settings-docs]: ../production/upgrade-or-modify.html#updating-settings-py-inline-documentation -[settings-py-template]: https://github.com/zulip/zulip/blob/master/zproject/prod_settings_template.py +[settings-py-template]: https://github.com/zulip/zulip/blob/main/zproject/prod_settings_template.py Since Zulip's settings file is a Python script, there are a number of other things that one can configure that are not documented; ask on diff --git a/docs/production/upgrade-or-modify.md b/docs/production/upgrade-or-modify.md index 83d3cd62df..07802e3818 100644 --- a/docs/production/upgrade-or-modify.md +++ b/docs/production/upgrade-or-modify.md @@ -10,7 +10,7 @@ This page explains how to upgrade, patch, or modify Zulip, including: - [Upgrading the operating system](#upgrading-the-operating-system) - [Upgrading PostgreSQL](#upgrading-postgresql) - [Modifying Zulip](#modifying-zulip) -- [Applying changes from master](#applying-changes-from-master) +- [Applying changes from main](#applying-changes-from-main) ## Upgrading to a release @@ -68,7 +68,7 @@ run into any issues or need to roll back the upgrade. Zulip supports upgrading a production installation to any commit in a Git repository, which is great for [running pre-release changes from -master](#applying-changes-from-master) or [maintaining a +main](#applying-changes-from-main) or [maintaining a fork](#making-changes). The process is simple: ```bash @@ -76,7 +76,7 @@ fork](#making-changes). The process is simple: /home/zulip/deployments/current/scripts/upgrade-zulip-from-git 1.8.1 # Upgrade to a branch (or other Git ref) /home/zulip/deployments/current/scripts/upgrade-zulip-from-git 2.1.x -/home/zulip/deployments/current/scripts/upgrade-zulip-from-git master +/home/zulip/deployments/current/scripts/upgrade-zulip-from-git main ``` Zulip will automatically fetch the relevant Git commit and upgrade to @@ -87,9 +87,9 @@ containing the changes planned for the next minor release (E.g. 2.1.5); we support these stable release branches as though they were a published release. -The `master` branch contains changes planned for the next major +The `main` branch contains changes planned for the next major release (E.g. 3.0); see our documentation on [running -master](#upgrading-to-master) before upgrading to it. +main](#upgrading-to-main) before upgrading to it. By default, this uses the main upstream Zulip server repository, but you can configure any other Git repository by adding a section like @@ -527,8 +527,8 @@ that fact: are related to the issue, just mention your changes in the issue report. If you're looking to modify Zulip by applying changes developed by the -Zulip core team and merged into master, skip to [this -section](#applying-changes-from-master). +Zulip core team and merged into main, skip to [this +section](#applying-changes-from-main). ## Making changes @@ -599,9 +599,9 @@ Eventually, you'll want to upgrade to a new Zulip release. If your changes were integrated into that Zulip release or are otherwise no longer needed, you can just [upgrade as usual](#upgrading-to-a-release). If you [upgraded to -master](#upgrading-to-master); review that section again; new +main](#upgrading-to-main); review that section again; new maintenance releases are likely "older" than your current installation -and you might need to upgrade to the master again rather than to the +and you might need to upgrade to the main again rather than to the new maintenance release. Otherwise, you'll need to update your branch by rebasing your changes @@ -640,7 +640,7 @@ different from the above: [docker-zulip]: https://github.com/zulip/docker-zulip [docker-zulip-upgrade]: https://github.com/zulip/docker-zulip#upgrading-from-a-git-repository -## Applying changes from master +## Applying changes from main If you are experiencing an issue that has already been fixed by the Zulip development community, and you'd like to get the fix now, you @@ -662,7 +662,7 @@ of the change you'd like). In general, we can't provide unpaid support for issues caused by cherry-picking arbitrary commits if the issues don't also affect -master or an official release. +main or an official release. The exception to this rule is when we ask or encourage a user to apply a change to their production system to help verify the fix resolves @@ -676,14 +676,14 @@ addition to scheduling that change for Zulip's next bug fix release, we support changes in stable release branches as though they were released. -### Upgrading to master +### Upgrading to main Many Zulip servers (including chat.zulip.org and zulip.com) upgrade to -master on a regular basis to get the latest features. Before doing +main on a regular basis to get the latest features. Before doing so, it's important to understand how to happily run a server based on -master. +main. -For background, it's backporting arbitrary patches from master to an +For background, it's backporting arbitrary patches from main to an older version requires some care. Common issues include: * Changes containing database migrations (new files under @@ -698,32 +698,32 @@ unlikely to succeed without help from the core team via a support contract. If you need an unreleased feature, the best path is usually to -upgrade to Zulip master using [upgrade-zulip-from-git][]. Before -upgrading to master, make sure you understand: +upgrade to Zulip main using [upgrade-zulip-from-git][]. Before +upgrading to main, make sure you understand: -* In Zulip's version numbering scheme, `master` will always be "newer" +* In Zulip's version numbering scheme, `main` will always be "newer" than the latest maintenance release (E.g. `3.1` or `2.1.6`) and "older" than the next major release (E.g. `3.0` or `4.0`). -* The `master` branch is under very active development; dozens of new - changes are integrated into it on most days. The `master` branch +* The `main` branch is under very active development; dozens of new + changes are integrated into it on most days. The `main` branch can have thousands of changes not present in the latest release (all of which will be included in our next major release). On average - `master` usually has fewer total bugs than the latest release + `main` usually has fewer total bugs than the latest release (because we fix hundreds of bugs in every major release) but it might have some bugs that are more severe than we would consider acceptable for a release. -* We deploy `master` to chat.zulip.org and zulip.com on a regular +* We deploy `main` to chat.zulip.org and zulip.com on a regular basis (often daily), so it's very important to the project that it be stable. Most regressions will be minor UX issues or be fixed quickly, because we need them to be fixed for Zulip Cloud. * The development community is very interested in helping debug issues - that arise when upgrading from the latest release to master, since + that arise when upgrading from the latest release to main, since they provide us an opportunity to fix that category of issue before our next major release. (Much more so than we are in helping folks debug other custom changes). That said, we cannot make any guarantees about how quickly we'll resolve an issue to folks without a formal support contract. -* We do not support downgrading from `master` to earlier versions, so +* We do not support downgrading from `main` to earlier versions, so if downtime for your Zulip server is unacceptable, make sure you have a current [backup](../production/export-and-import.html#backups) in case the @@ -733,11 +733,11 @@ upgrading to master, make sure you understand: since the last release. The **Upgrade notes** section will always be current, even if some new features aren't documented. * Whenever we push a security or maintenance release, the changes in - that release will always be merged to master; so you can get the - security fixes by upgrading to master. -* You can always upgrade from master to the next major release when it + that release will always be merged to main; so you can get the + security fixes by upgrading to main. +* You can always upgrade from main to the next major release when it comes out, using either [upgrade-zulip-from-git][] or the release - tarball. So there's no risk of upgrading to `master` resulting in + tarball. So there's no risk of upgrading to `main` resulting in a system that's not upgradeable back to a normal release. ## Contributing patches diff --git a/docs/subsystems/dependencies.md b/docs/subsystems/dependencies.md index 9e46cf8bb9..359a14c1de 100644 --- a/docs/subsystems/dependencies.md +++ b/docs/subsystems/dependencies.md @@ -208,7 +208,7 @@ See the [README][requirements-readme] file in `requirements/` directory to learn how to upgrade a single Python package. [mypy-docs]: ../testing/mypy.md -[requirements-readme]: https://github.com/zulip/zulip/blob/master/requirements/README.md#requirements +[requirements-readme]: https://github.com/zulip/zulip/blob/main/requirements/README.md#requirements [stack-overflow]: https://askubuntu.com/questions/8653/how-to-keep-processes-running-after-ending-ssh-session [caching]: https://help.github.com/en/articles/caching-your-github-password-in-git @@ -333,7 +333,7 @@ usually one needs to think about making changes in 3 places: to be called from `tools/update-prod-static`, which is called by `tools/build-release-tarball` (for doing Zulip releases) as well as `tools/upgrade-zulip-from-git` (for deploying a Zulip server off of - master). + main). [virtualenv]: https://virtualenv.pypa.io/en/stable/ [virtualenv-clone]: https://github.com/edwardgeorge/virtualenv-clone/ diff --git a/docs/subsystems/events-system.md b/docs/subsystems/events-system.md index f9a8cae3d9..b99e32d939 100644 --- a/docs/subsystems/events-system.md +++ b/docs/subsystems/events-system.md @@ -407,7 +407,7 @@ correctly, clients are responsible for discarding events related to messages that the client has not yet fetched. Additionally, see -[the master documentation on sending messages](../subsystems/sending-messages.md). +[the main documentation on sending messages](../subsystems/sending-messages.md). ## Schema changes diff --git a/docs/subsystems/release-checklist.md b/docs/subsystems/release-checklist.md index 90b54feed0..c435457fdd 100644 --- a/docs/subsystems/release-checklist.md +++ b/docs/subsystems/release-checklist.md @@ -43,7 +43,7 @@ preparing a new release. ### Executing the release -* Create the release commit, on master (for major releases) or on the +* Create the release commit, on main (for major releases) or on the release branch (for minor releases): * Copy the Markdown release notes for the release into `docs/overview/changelog.md`. @@ -60,7 +60,7 @@ preparing a new release. GitHub](https://github.com/zulip/zulip/tags); use the text from `changelog.md` for the release notes. - **Note:** This will trigger the [GitHub action](https://github.com/zulip/zulip/blob/master/tools/oneclickapps/README.md) + **Note:** This will trigger the [GitHub action](https://github.com/zulip/zulip/blob/main/tools/oneclickapps/README.md) for updating DigitalOcean one-click app image. The action uses the latest release tarball published on `download.zulip.com` for creating the image. * Update the [Docker image](https://github.com/zulip/docker-zulip) and @@ -79,7 +79,7 @@ preparing a new release. * Create a release branch (e.g. `4.x`). * On the release branch, update `ZULIP_VERSION` in `version.py` to the present release with a `+git` suffix, e.g. `4.0+git`. - * On master, update `ZULIP_VERSION` to the future major release with + * On main, update `ZULIP_VERSION` to the future major release with a `-dev+git` suffix, e.g. `5.0-dev+git`. Make a Git tag for this update commit with a `-dev` suffix, e.g. `5.0-dev`. Push the tag to both zulip.git and zulip-internal.git to get a correct version @@ -90,4 +90,4 @@ preparing a new release. * Update `ZULIP_VERSION` to the present release with a `+git` suffix, e.g. `3.2+git`. * Update `LATEST_RELEASE_VERSION` with the released version. - * Cherry-pick the changelog changes back to `master`. + * Cherry-pick the changelog changes back to `main`. diff --git a/docs/testing/linters.md b/docs/testing/linters.md index cbf0837e88..f3ea792623 100644 --- a/docs/testing/linters.md +++ b/docs/testing/linters.md @@ -133,14 +133,14 @@ It is the workhorse of our linting system, although in some cases it dispatches the heavy lifting to other components such as pyflakes, eslint, and other home grown tools. -You can find the source code [here](https://github.com/zulip/zulip/blob/master/tools/lint). +You can find the source code [here](https://github.com/zulip/zulip/blob/main/tools/lint). In order for our entire lint suite to run in a timely fashion, the `lint` script performs several lint checks in parallel by forking out subprocesses. Note that our project does custom regex-based checks on the code, and we also customize how we call pyflakes and pycodestyle (pep8). The code for these -types of checks mostly lives [here](https://github.com/zulip/zulip/tree/master/tools/linter_lib). +types of checks mostly lives [here](https://github.com/zulip/zulip/tree/main/tools/linter_lib). ### Special options @@ -216,8 +216,8 @@ Zulip uses two HTML templating systems: Zulip has an internal tool that validates both types of templates for correct indentation and matching tags. You can find the code here: -- driver: [check-templates](https://github.com/zulip/zulip/blob/master/tools/check-templates) -- engine: [lib/template_parser.py](https://github.com/zulip/zulip/blob/master/tools/lib/template_parser.py) +- driver: [check-templates](https://github.com/zulip/zulip/blob/main/tools/check-templates) +- engine: [lib/template_parser.py](https://github.com/zulip/zulip/blob/main/tools/lib/template_parser.py) We exempt some legacy files from indentation checks, but we are hoping to clean those files up eventually. @@ -226,7 +226,7 @@ clean those files up eventually. Zulip uses [stylelint](https://github.com/stylelint/stylelint) to lint its CSS; see our -[configuration](https://github.com/zulip/zulip/blob/master/stylelint.config.js) +[configuration](https://github.com/zulip/zulip/blob/main/stylelint.config.js) for the rules we currently enforce. #### Shell scripts diff --git a/docs/testing/testing-with-django.md b/docs/testing/testing-with-django.md index eb30440f64..61654c280b 100644 --- a/docs/testing/testing-with-django.md +++ b/docs/testing/testing-with-django.md @@ -69,7 +69,7 @@ Before you write your first tests of Zulip, it is worthwhile to read the rest of this document. To get a hang of commonly used testing techniques, read -[zerver/tests/test_example.py](https://github.com/zulip/zulip/blob/master/zerver/tests/test_example.py). +[zerver/tests/test_example.py](https://github.com/zulip/zulip/blob/main/zerver/tests/test_example.py). You can also read some of the existing tests in `zerver/tests` to get a feel for other patterns we use. @@ -83,9 +83,9 @@ accidentally regresses the feature in the future, the test will catch the regression. Another important files to skim are -[zerver/lib/test_helpers.py](https://github.com/zulip/zulip/blob/master/zerver/lib/test_helpers.py), +[zerver/lib/test_helpers.py](https://github.com/zulip/zulip/blob/main/zerver/lib/test_helpers.py), which contains test helpers. -[zerver/lib/test_classes.py](https://github.com/zulip/zulip/blob/master/zerver/lib/test_classes.py), +[zerver/lib/test_classes.py](https://github.com/zulip/zulip/blob/main/zerver/lib/test_classes.py), which contains our `ZulipTestCase` and `WebhookTestCase` classes. ### Setting up data for tests @@ -416,7 +416,7 @@ A detailed description of mocks, along with useful coded snippets, can be found ### Template tests -In [zerver/tests/test_templates.py](https://github.com/zulip/zulip/blob/master/zerver/tests/test_templates.py) +In [zerver/tests/test_templates.py](https://github.com/zulip/zulip/blob/main/zerver/tests/test_templates.py) we have a test that renders all of our backend templates with a "dummy" context, to make sure the templates don't have obvious errors. (These tests won't catch all types of errors; they are diff --git a/docs/testing/testing-with-node.md b/docs/testing/testing-with-node.md index cc3c305474..1ea7f90d59 100644 --- a/docs/testing/testing-with-node.md +++ b/docs/testing/testing-with-node.md @@ -44,7 +44,7 @@ there are, you should strive to follow the patterns of the existing tests and add your own tests. A good first test to read is -[example1.js](https://github.com/zulip/zulip/blob/master/frontend_tests/node_tests/example1.js). +[example1.js](https://github.com/zulip/zulip/blob/main/frontend_tests/node_tests/example1.js). (And then there are several other example files.) ## How the node tests work @@ -59,10 +59,10 @@ those slow down the tests a lot, and often don't add much value. Instead, the preferred model for our unit tests is to mock DOM manipulations (which in Zulip are almost exclusively done via `jQuery`) using a custom library -[zjquery](https://github.com/zulip/zulip/blob/master/frontend_tests/zjsunit/zjquery.js). +[zjquery](https://github.com/zulip/zulip/blob/main/frontend_tests/zjsunit/zjquery.js). The -[unit test file](https://github.com/zulip/zulip/blob/master/frontend_tests/node_tests/zjquery.js) +[unit test file](https://github.com/zulip/zulip/blob/main/frontend_tests/node_tests/zjquery.js) for `zjquery` is designed to be also serve as nice documentation for how to use `zjquery`, and is **highly recommended reading** for anyone working on or debugging the Zulip node tests. diff --git a/docs/testing/testing-with-puppeteer.md b/docs/testing/testing-with-puppeteer.md index c591bf9e0f..12f00e6a98 100644 --- a/docs/testing/testing-with-puppeteer.md +++ b/docs/testing/testing-with-puppeteer.md @@ -137,7 +137,7 @@ notes above: verify it does not fail nondeterminstically (see above for notes on how to get CI to do it for you); this is important to avoid introducing extremely annoying nondeterministic failures into - master. + main. - With black-box browser tests like these, it's very important to write your code to wait for browser's UI to update before taking any action that assumes the last step was processed by the browser (E.g. after you diff --git a/docs/translating/translating.md b/docs/translating/translating.md index 85ef92badd..c4624e4e78 100644 --- a/docs/translating/translating.md +++ b/docs/translating/translating.md @@ -61,7 +61,7 @@ to any languages that you'd like to contribute to (or add new ones). 1. If possible, test your translations (details below). 1. Ask in Zulip for a maintainer to sync the strings from Transifex, - merge them to master, and deploy the update to chat.zulip.org so + merge them to main, and deploy the update to chat.zulip.org so you can verify them in action there. Some useful tips for your translating journey: diff --git a/docs/tutorials/life-of-a-request.md b/docs/tutorials/life-of-a-request.md index a54f00c55e..c43befdf96 100644 --- a/docs/tutorials/life-of-a-request.md +++ b/docs/tutorials/life-of-a-request.md @@ -20,7 +20,7 @@ are in your Git checkout under `static`, and are served unminified. ## Static files are [served directly][served-directly] by Nginx -[served-directly]: https://github.com/zulip/zulip/blob/master/puppet/zulip/files/nginx/zulip-include-frontend/app +[served-directly]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-frontend/app Static files include JavaScript, css, static assets (like emoji, avatars), and user uploads (if stored locally and not on S3). @@ -50,7 +50,7 @@ application. [Here is the relevant nginx routing configuration.][nginx-config-link] -[nginx-config-link]: https://github.com/zulip/zulip/blob/master/puppet/zulip/files/nginx/zulip-include-frontend/app +[nginx-config-link]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-frontend/app ## Django routes the request to a view in urls.py files @@ -70,7 +70,7 @@ on how the REST API handles our user creation example. ## Views serving HTML are internationalized by server path If we look in -[zproject/urls.py](https://github.com/zulip/zulip/blob/master/zproject/urls.py), +[zproject/urls.py](https://github.com/zulip/zulip/blob/main/zproject/urls.py), we can see something called `i18n_urls`. These urls show up in the address bar of the browser, and serve HTML. @@ -135,7 +135,7 @@ This request: yields a response with this HTTP header: `Allow: PUT, GET` -We can see this reflected in [zproject/urls.py](https://github.com/zulip/zulip/blob/master/zproject/urls.py): +We can see this reflected in [zproject/urls.py](https://github.com/zulip/zulip/blob/main/zproject/urls.py): ```python rest_path('users', @@ -151,7 +151,7 @@ The endpoints from the legacy JSON API are written without REST in mind. They are used extensively by the web client, and use POST. You can see them in -[zproject/legacy_urls.py](https://github.com/zulip/zulip/blob/master/zproject/legacy_urls.py). +[zproject/legacy_urls.py](https://github.com/zulip/zulip/blob/main/zproject/legacy_urls.py). ### Incoming webhook integrations may not be RESTful @@ -163,7 +163,7 @@ only POST. For requests that correspond to a REST url pattern, Zulip configures its url patterns (see -[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/master/zerver/lib/rest.py)) +[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/main/zerver/lib/rest.py)) so that the action called is `rest_dispatch`. This method will authenticate the user, either through a session token from a cookie, or from an `email:api-key` string given via HTTP basic auth for API diff --git a/docs/tutorials/writing-views.md b/docs/tutorials/writing-views.md index d62e4e524d..865cb65d2e 100644 --- a/docs/tutorials/writing-views.md +++ b/docs/tutorials/writing-views.md @@ -98,7 +98,7 @@ def home(request: HttpRequest) -> HttpResponse: ### Writing a template Templates for the main website are found in -[templates/zerver/app](https://github.com/zulip/zulip/tree/master/templates/zerver/app). +[templates/zerver/app](https://github.com/zulip/zulip/tree/main/templates/zerver/app). ## Writing API REST endpoints @@ -109,7 +109,7 @@ view code is in the implementations of API REST endpoints. The REST API does authentication of the user through `rest_dispatch`, which is documented in detail at -[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/master/zerver/lib/rest.py). +[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/main/zerver/lib/rest.py). This method will authenticate the user either through a session token from a cookie on the browser, or from a base64 encoded `email:api-key` string given via HTTP basic auth for API clients. @@ -174,7 +174,7 @@ the inner decorator. The implementation of `has_request_variables` is documented in detail in -[zerver/lib/request.py](https://github.com/zulip/zulip/blob/master/zerver/lib/request.py)) +[zerver/lib/request.py](https://github.com/zulip/zulip/blob/main/zerver/lib/request.py)) REQ also helps us with request variable validation. For example: @@ -200,7 +200,7 @@ REQ also helps us with request variable validation. For example: validator on the value of a string. See -[zerver/lib/validator.py](https://github.com/zulip/zulip/blob/master/zerver/lib/validator.py) +[zerver/lib/validator.py](https://github.com/zulip/zulip/blob/main/zerver/lib/validator.py) for more validators and their documentation. ### Deciding which HTTP verb to use @@ -214,7 +214,7 @@ be read with GET, without the expense of the full GET. OPTIONS is also read-only, and used by clients to determine which HTTP verbs are available for a given path. This isn't something you need to write, as it happens automatically in the implementation of `rest_dispatch`--see -[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/master/zerver/lib/rest.py) +[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/main/zerver/lib/rest.py) for more. If you're creating new data, try to figure out if the thing you are @@ -259,7 +259,7 @@ database) and lead to a 500 error. If an actions function is responsible for validation as well, it should have a name starting with `check_`. -For example, in [zerver/views/realm.py](https://github.com/zulip/zulip/blob/master/zerver/views/realm.py): +For example, in [zerver/views/realm.py](https://github.com/zulip/zulip/blob/main/zerver/views/realm.py): ```py @require_realm_admin @@ -284,7 +284,7 @@ Zulip realm). You should always use `channel.` to make an `HTTP ` call to the Zulip JSON API. As an example, in -[static/js/admin.js](https://github.com/zulip/zulip/blob/master/static/js/admin.js) +[static/js/admin.js](https://github.com/zulip/zulip/blob/main/static/js/admin.js) ```js var url = "/json/realm"; diff --git a/frontend_tests/node_tests/zblueslip.js b/frontend_tests/node_tests/zblueslip.js index 16252ca754..85e65d65fd 100644 --- a/frontend_tests/node_tests/zblueslip.js +++ b/frontend_tests/node_tests/zblueslip.js @@ -23,7 +23,7 @@ What is zblueslip? The code we are testing lives here: - https://github.com/zulip/zulip/blob/master/frontend_tests/zjsunit/zblueslip.js + https://github.com/zulip/zulip/blob/main/frontend_tests/zjsunit/zblueslip.js Read the following contents for an overview of how zblueslip works. Also take a look at `node_tests/people_errors.js` for actual usage of this module. diff --git a/frontend_tests/node_tests/zjquery.js b/frontend_tests/node_tests/zjquery.js index c9d8b3108e..9271ea7be5 100644 --- a/frontend_tests/node_tests/zjquery.js +++ b/frontend_tests/node_tests/zjquery.js @@ -25,7 +25,7 @@ What is zjquery? The code we are testing lives here: - https://github.com/zulip/zulip/blob/master/frontend_tests/zjsunit/zjquery.js + https://github.com/zulip/zulip/blob/main/frontend_tests/zjsunit/zjquery.js */ diff --git a/templates/zerver/api/incoming-webhooks-overview.md b/templates/zerver/api/incoming-webhooks-overview.md index 5d77640dfc..a004d7f5b8 100644 --- a/templates/zerver/api/incoming-webhooks-overview.md +++ b/templates/zerver/api/incoming-webhooks-overview.md @@ -66,7 +66,7 @@ process. * Document the integration (required for getting it merged into Zulip). You can template off an existing guide, like - [this one](https://raw.githubusercontent.com/zulip/zulip/master/zerver/webhooks/github/doc.md). + [this one](https://raw.githubusercontent.com/zulip/zulip/main/zerver/webhooks/github/doc.md). This should not take more than 15 minutes, even if you don't speak English as a first language (we'll clean up the text before merging). diff --git a/templates/zerver/api/incoming-webhooks-walkthrough.md b/templates/zerver/api/incoming-webhooks-walkthrough.md index d329db88ee..3249e2a133 100644 --- a/templates/zerver/api/incoming-webhooks-walkthrough.md +++ b/templates/zerver/api/incoming-webhooks-walkthrough.md @@ -456,7 +456,7 @@ See [our guide on documenting an integration][integration-docs-guide] for further details, including how to easily create the message screenshot. Mostly you should plan on templating off an existing guide, like -[this one](https://raw.githubusercontent.com/zulip/zulip/master/zerver/webhooks/github/doc.md). +[this one](https://raw.githubusercontent.com/zulip/zulip/main/zerver/webhooks/github/doc.md). [integration-docs-guide]: https://zulip.readthedocs.io/en/latest/documentation/integrations.html diff --git a/templates/zerver/api/integrations-overview.md b/templates/zerver/api/integrations-overview.md index 116a9fd401..cbe70038bc 100644 --- a/templates/zerver/api/integrations-overview.md +++ b/templates/zerver/api/integrations-overview.md @@ -65,5 +65,5 @@ us](/help/contact-support) and we'll see what we can do. built on top of this API, so it can do anything a human user can do. Most but not all of the endpoints are documented on this site; if you need something that isn't there check out Zulip's - [REST endpoints](https://github.com/zulip/zulip/blob/master/zproject/urls.py) + [REST endpoints](https://github.com/zulip/zulip/blob/main/zproject/urls.py) or [contact us](/help/contact-support) and we'll help you out. diff --git a/templates/zerver/help/import-from-mattermost.md b/templates/zerver/help/import-from-mattermost.md index f5aa2409a0..c999c4b8c9 100644 --- a/templates/zerver/help/import-from-mattermost.md +++ b/templates/zerver/help/import-from-mattermost.md @@ -139,7 +139,7 @@ skipping "Step 3: Create a Zulip organization, and log in" (you'll create your Zulip organization via the data import tool instead). Use [upgrade-zulip-from-git][upgrade-zulip-from-git] to -upgrade your Zulip server to the latest `master` branch. +upgrade your Zulip server to the latest `main` branch. Log in to a shell on your Zulip server as the `zulip` user. To import with the most common configuration, run the following commands, replacing diff --git a/templates/zerver/help/include/git-append-branches.md b/templates/zerver/help/include/git-append-branches.md index ffc6f4fcc3..952b0a17c3 100644 --- a/templates/zerver/help/include/git-append-branches.md +++ b/templates/zerver/help/include/git-append-branches.md @@ -1,4 +1,4 @@ You can also limit the notifications you receive to specific branches -by appending `?branches=master,development` to the end of the URL, -where `master` and `development` are the branches you'd like to be +by appending `?branches=main,development` to the end of the URL, +where `main` and `development` are the branches you'd like to be notified about. diff --git a/templates/zerver/help/include/git-webhook-url-with-branches-indented.md b/templates/zerver/help/include/git-webhook-url-with-branches-indented.md index 5bba6db1ae..52816be331 100644 --- a/templates/zerver/help/include/git-webhook-url-with-branches-indented.md +++ b/templates/zerver/help/include/git-webhook-url-with-branches-indented.md @@ -1,4 +1,4 @@ You can also limit the branches you receive notifications for by specifying them in a comma-separated list at the end of the URL, like so: - `{{ api_url }}{{ integration_url }}?api_key=abcdefgh&stream={{ recommended_stream_name }}&branches=master,development` + `{{ api_url }}{{ integration_url }}?api_key=abcdefgh&stream={{ recommended_stream_name }}&branches=main,development` diff --git a/templates/zerver/help/include/git-webhook-url-with-branches.md b/templates/zerver/help/include/git-webhook-url-with-branches.md index b4613907b7..a5d5bc41de 100644 --- a/templates/zerver/help/include/git-webhook-url-with-branches.md +++ b/templates/zerver/help/include/git-webhook-url-with-branches.md @@ -2,4 +2,4 @@ You can also limit the branches you receive notifications for by specifying them in a comma-separated list at the end of the URL, like so: -`{{ api_url }}{{ integration_url }}?api_key=abcdefgh&stream={{ recommended_stream_name }}&branches=master,development` +`{{ api_url }}{{ integration_url }}?api_key=abcdefgh&stream={{ recommended_stream_name }}&branches=main,development` diff --git a/tools/cache-zulip-git-version b/tools/cache-zulip-git-version index e125e1187c..b025a6b4a7 100755 --- a/tools/cache-zulip-git-version +++ b/tools/cache-zulip-git-version @@ -5,7 +5,7 @@ cd "$(dirname "$0")/.." remote="$(git config zulip.zulipRemote)" || remote=upstream { git describe --always --tags --match='[0-9]*' - branches="$(git for-each-ref --format='%(objectname)' "refs/remotes/$remote/master" "refs/remotes/$remote/*.x")" + branches="$(git for-each-ref --format='%(objectname)' "refs/remotes/$remote/main" "refs/remotes/$remote/*.x")" mapfile -t branches <<<"$branches" if merge_base="$(git merge-base -- HEAD "${branches[@]}")"; then git describe --always --tags --match='[0-9]*' -- "$merge_base" diff --git a/tools/clean-branches b/tools/clean-branches index 18451839d9..d0e5f76685 100755 --- a/tools/clean-branches +++ b/tools/clean-branches @@ -2,9 +2,9 @@ set -e # usage: clean-branches -# Deletes any local branches which are ancestors of origin/master, +# Deletes any local branches which are ancestors of origin/main, # and also any branches in origin which are ancestors of -# origin/master and are named like $USER-*. +# origin/main and are named like $USER-*. # usage: clean-branches --reviews # Deletes all the above mentioned branches as well as branches @@ -18,13 +18,13 @@ fi push_args=() function is_merged() { - ! git rev-list -n 1 origin/master.."$1" | grep -q . + ! git rev-list -n 1 origin/main.."$1" | grep -q . } function clean_ref() { ref="$1" case "$ref" in - */master | */HEAD) + */main | */HEAD) return ;; @@ -56,8 +56,8 @@ function clean_ref() { esac } -if [ "$(git symbolic-ref HEAD)" != 'refs/heads/master' ]; then - echo "Check out master before you run this script." >&2 +if [ "$(git symbolic-ref HEAD)" != 'refs/heads/main' ]; then + echo "Check out main before you run this script." >&2 exit 1 fi diff --git a/tools/commit-message-lint b/tools/commit-message-lint index 74d093c8a7..418d172c4c 100755 --- a/tools/commit-message-lint +++ b/tools/commit-message-lint @@ -1,6 +1,6 @@ #!/usr/bin/env bash -# Lint all commit messages that are newer than upstream/master if running +# Lint all commit messages that are newer than upstream/main if running # locally or the commits in the push or PR if in CircleCI. # The rules can be found in /.gitlint @@ -12,9 +12,9 @@ $(git remote -v) " =~ ' '([^[:space:]]*)[[:space:]]*(https://github\.com/|ssh://git@github\.com/|git@github\.com:)"$repository"(\.git|/)?\ \(fetch\)' ' ]]; then - range="${BASH_REMATCH[1]}/master..HEAD" + range="${BASH_REMATCH[1]}/main..HEAD" else - range="upstream/master..HEAD" + range="upstream/main..HEAD" fi commits=$(git log "$range" | wc -l) diff --git a/tools/deploy-branch b/tools/deploy-branch index 8649392b6e..120d917dfd 100755 --- a/tools/deploy-branch +++ b/tools/deploy-branch @@ -15,7 +15,7 @@ branch=$1 branch_ref=$(git rev-list --max-count=1 "$branch") || error_out "Unknown branch: $branch" if [ "$old_ref" == "$branch_ref" ]; then - new_ref=master + new_ref=main else if ref_name=$(git describe --all --exact "$old_ref"); then new_ref=$(echo "$ref_name" | perl -pe 's{^(heads|remotes)/}{}') @@ -28,10 +28,10 @@ fi git fetch -p -git rebase origin/master "$branch" || error_out "Rebase onto origin/master failed" +git rebase origin/main "$branch" || error_out "Rebase onto origin/main failed" -git push . HEAD:master -git push origin master || error_out "Push of master to origin/master failed" +git push . HEAD:main +git push origin main || error_out "Push of main to origin/main failed" git checkout "$new_ref" git branch -D "$branch" diff --git a/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py b/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py index 025865d949..00cf15faf9 100644 --- a/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py +++ b/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py @@ -32,7 +32,7 @@ EXCLUDED_URLS = [ "https://www.transifex.com/zulip/zulip/announcements/", "https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh", # Requires authentication - "https://circleci.com/gh/zulip/zulip/tree/master", + "https://circleci.com/gh/zulip/zulip/tree/main", "https://circleci.com/gh/zulip/zulip/16617", "https://www.linkedin.com/company/zulip-project", # Returns 403 errors to HEAD requests @@ -54,8 +54,8 @@ VNU_IGNORE_REGEX = re.compile(r"|".join(VNU_IGNORE)) DEPLOY_ROOT = os.path.abspath(os.path.join(__file__, "../../../../../..")) -ZULIP_SERVER_GITHUB_FILE_URL_PREFIX = "https://github.com/zulip/zulip/blob/master" -ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX = "https://github.com/zulip/zulip/tree/master" +ZULIP_SERVER_GITHUB_FILE_URL_PREFIX = "https://github.com/zulip/zulip/blob/main" +ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX = "https://github.com/zulip/zulip/tree/main" class BaseDocumentationSpider(scrapy.Spider): diff --git a/tools/droplets/README.md b/tools/droplets/README.md index 337d6403f4..115def184f 100644 --- a/tools/droplets/README.md +++ b/tools/droplets/README.md @@ -127,7 +127,7 @@ Rough steps: probably have to be logged in in the Zulip organization view, rather than via your personal account. 1. `ssh zulipdev@base.zulipdev.org` -1. `git pull upstream master` +1. `git pull upstream main` 1. `tools/provision` 1. `git clean -f`, in case things were added/removed from `.gitignore`. 1. `tools/run-dev.py`, let it run to completion, and then Ctrl-C (to clear diff --git a/tools/fetch-rebase-pull-request b/tools/fetch-rebase-pull-request index 31ff4cdf75..8c282b867c 100755 --- a/tools/fetch-rebase-pull-request +++ b/tools/fetch-rebase-pull-request @@ -12,6 +12,6 @@ remote=${2:-"upstream"} set -x git fetch "$remote" "pull/$request_id/head" -git checkout -B "review-${request_id}" "$remote/master" +git checkout -B "review-${request_id}" "$remote/main" git reset --hard FETCH_HEAD git pull --rebase diff --git a/tools/lib/test_script.py b/tools/lib/test_script.py index e2e862891d..59087af916 100644 --- a/tools/lib/test_script.py +++ b/tools/lib/test_script.py @@ -39,7 +39,7 @@ NEED_TO_DOWNGRADE = """ It looks like you checked out a branch that expects an older version of dependencies than the version you provisioned last. This may be ok, but it's likely that you either want to rebase -your branch on top of upstream/master or re-provision your VM. +your branch on top of upstream/main or re-provision your VM. Do this: `./tools/provision` """ diff --git a/tools/push-to-pull-request b/tools/push-to-pull-request index 46cb8970ab..4b3c5320b3 100755 --- a/tools/push-to-pull-request +++ b/tools/push-to-pull-request @@ -7,9 +7,9 @@ usage: $0 [--merge] PULL_REQUEST_ID [REMOTE] Force-push our HEAD to the given GitHub pull request branch. -Useful for a maintainer to run just before pushing to master, +Useful for a maintainer to run just before pushing to main, after tweaking the branch and/or rebasing to latest. This causes -GitHub to see the subsequent push to master as representing a +GitHub to see the subsequent push to main as representing a merge of the PR, rather than requiring the PR to be manually (and to the casual observer misleadingly) closed instead. diff --git a/tools/review b/tools/review index 0a4bab6ce3..98b5540b60 100755 --- a/tools/review +++ b/tools/review @@ -33,21 +33,21 @@ def check_git_pristine() -> None: exit("Git is not pristine:\n" + output) -def ensure_on_clean_master() -> None: +def ensure_on_clean_main() -> None: branch = get_git_branch() - if branch != "master": + if branch != "main": exit(f"You are still on a feature branch: {branch}") check_git_pristine() - run(["git", "fetch", "upstream", "master"]) - run(["git", "rebase", "upstream/master"]) + run(["git", "fetch", "upstream", "main"]) + run(["git", "rebase", "upstream/main"]) def create_pull_branch(pull_id: int) -> None: run(["git", "fetch", "upstream", f"pull/{pull_id}/head"]) run(["git", "checkout", "-B", f"review-{pull_id}", "FETCH_HEAD"]) - run(["git", "rebase", "upstream/master"]) - run(["git", "log", "upstream/master..", "--oneline"]) - run(["git", "diff", "upstream/master..", "--name-status"]) + run(["git", "rebase", "upstream/main"]) + run(["git", "log", "upstream/main..", "--oneline"]) + run(["git", "diff", "upstream/main..", "--name-status"]) print() print(f"PR: {pull_id}") @@ -60,7 +60,7 @@ def review_pr() -> None: except Exception: exit("please provide an integer pull request id") - ensure_on_clean_master() + ensure_on_clean_main() create_pull_branch(pull_id) diff --git a/tools/setup/install-aws-server b/tools/setup/install-aws-server index ba9481de74..dc805c82d9 100755 --- a/tools/setup/install-aws-server +++ b/tools/setup/install-aws-server @@ -18,7 +18,7 @@ if [ -z "$SERVER" ] || [ -z "$ROLES" ]; then echo echo "[repo]" echo "repo_url=git@github.com:zulip/zulip.git" - echo "branch=master" + echo "branch=main" echo "[aws]" echo "zone_id=Z2U988IEXAMPLE" echo "security_groups=sg-01234567" diff --git a/zerver/lib/markdown/__init__.py b/zerver/lib/markdown/__init__.py index b71822292e..5e6b247d2e 100644 --- a/zerver/lib/markdown/__init__.py +++ b/zerver/lib/markdown/__init__.py @@ -714,8 +714,8 @@ class InlineInterestingLinkProcessor(markdown.treeprocessors.Treeprocessor): # See https://github.com/zulip/zulip/issues/4658 for more information parsed_url = urllib.parse.urlparse(url) if parsed_url.netloc == "github.com" or parsed_url.netloc.endswith(".github.com"): - # https://github.com/zulip/zulip/blob/master/static/images/logo/zulip-icon-128x128.png -> - # https://raw.githubusercontent.com/zulip/zulip/master/static/images/logo/zulip-icon-128x128.png + # https://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png -> + # https://raw.githubusercontent.com/zulip/zulip/main/static/images/logo/zulip-icon-128x128.png split_path = parsed_url.path.split("/") if len(split_path) > 3 and split_path[3] == "blob": return urllib.parse.urljoin( diff --git a/zerver/lib/test_data.source.txt b/zerver/lib/test_data.source.txt index 2e5c733f70..486f0cb543 100644 --- a/zerver/lib/test_data.source.txt +++ b/zerver/lib/test_data.source.txt @@ -165,7 +165,7 @@ This project seems to be proceeding well; I'm looking forward to testing it out soon. I should clarify what I said earlier about "not having anything since 1.6 -related to this." On master we are actually touching a lot of email-related +related to this." On main we are actually touching a lot of email-related code. ah, I see, the other files just isolated them, makes sense. I guess I'll diff --git a/zerver/migrations/0209_user_profile_no_empty_password.py b/zerver/migrations/0209_user_profile_no_empty_password.py index 2a6240730b..40d98b22c5 100644 --- a/zerver/migrations/0209_user_profile_no_empty_password.py +++ b/zerver/migrations/0209_user_profile_no_empty_password.py @@ -60,7 +60,7 @@ def ensure_no_empty_passwords(apps: StateApps, schema_editor: DatabaseSchemaEdit # Because we're backporting this migration to the Zulip 2.0.x # series, we've given it migration number 0209, which is a # duplicate with an existing migration already merged into Zulip - # master. Migration 0247_realmauditlog_event_type_to_int.py + # main. Migration 0247_realmauditlog_event_type_to_int.py # changes the format of RealmAuditLog.event_type, so we need the # following conditional block to determine what values to use when # searching for the relevant events in that log. diff --git a/zerver/tests/test_example.py b/zerver/tests/test_example.py index d51bb98202..c6230ccd5b 100644 --- a/zerver/tests/test_example.py +++ b/zerver/tests/test_example.py @@ -364,7 +364,7 @@ class TestQueryCounts(ZulipTestCase): # fails, we'll want to understand the new queries and whether # they're necessary. You can investiate whether the changes # are expected/sensible by comparing print(queries) between - # your branch and master. + # your branch and main. hamlet = self.example_user("hamlet") cordelia = self.example_user("cordelia") diff --git a/zerver/tests/test_markdown.py b/zerver/tests/test_markdown.py index 7cf5acf96d..1e6b7c6132 100644 --- a/zerver/tests/test_markdown.py +++ b/zerver/tests/test_markdown.py @@ -837,12 +837,12 @@ class MarkdownTest(ZulipTestCase): def test_inline_github_preview(self) -> None: # Test photo album previews - msg = "Test: https://github.com/zulip/zulip/blob/master/static/images/logo/zulip-icon-128x128.png" + msg = "Test: https://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png" converted = markdown_convert_wrapper(msg) self.assertEqual( converted, - '

Test: https://github.com/zulip/zulip/blob/master/static/images/logo/zulip-icon-128x128.png

\n
', + '

Test: https://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png

\n
', ) msg = "Test: https://developer.github.com/assets/images/hero-circuit-bg.png" diff --git a/zerver/tornado/event_queue.py b/zerver/tornado/event_queue.py index 4b05a81b12..76f8f59801 100644 --- a/zerver/tornado/event_queue.py +++ b/zerver/tornado/event_queue.py @@ -1104,7 +1104,7 @@ def process_message_update_event( # TODO/compatibility: Translation code for the rename of # `push_notify_user_ids` to `online_push_user_ids`. Remove this - # when one can no longer directly upgrade from 4.x to master. + # when one can no longer directly upgrade from 4.x to main. online_push_user_ids = set() if "online_push_user_ids" in event_template: online_push_user_ids = set(event_template.pop("online_push_user_ids")) @@ -1290,7 +1290,7 @@ def process_notification(notice: Mapping[str, Any]) -> None: # queue at the time of upgrade. # # TODO/compatibility: Remove this block once you can no - # longer directly upgrade directly from 4.x to master. + # longer directly upgrade directly from 4.x to main. user_ids: List[int] = [user["id"] for user in cast(List[Mapping[str, Any]], users)] else: user_ids = cast(List[int], users) diff --git a/zerver/worker/queue_processors.py b/zerver/worker/queue_processors.py index ff3101d4ec..af10e5298e 100644 --- a/zerver/worker/queue_processors.py +++ b/zerver/worker/queue_processors.py @@ -508,7 +508,7 @@ class UserActivityWorker(LoopQueueProcessingWorker): # event["client_id"] directly. # # TODO/compatibility: We can delete this once it is no - # longer possible to directly upgrade from 2.1 to master. + # longer possible to directly upgrade from 2.1 to main. if event["client"] not in self.client_id_map: client = get_client(event["client"]) self.client_id_map[event["client"]] = client.id