Rename 'master' branch to 'main'

CONTRIBUTING.md

@@ -26,21 +26,21 @@ there are many other ways how to contribute to the LibrePCB project, see
 - Open a new issue for your idea, assuming one does not already exist.
 - Fork the repository on GitHub.
 - Have a look at our
-  [development resources](https://github.com/LibrePCB/LibrePCB/tree/master/dev),
+  [development resources](https://github.com/LibrePCB/LibrePCB/tree/main/dev),
   especially at the [developers documentation](https://developers.librepcb.org/).
 - When using QtCreator, import and use our
-  [code style guide file](https://github.com/LibrePCB/LibrePCB/blob/master/dev/CodingStyle_QtCreator.xml).
+  [code style guide file](https://github.com/LibrePCB/LibrePCB/blob/main/dev/CodingStyle_QtCreator.xml).
 
 ## Making Changes
 
 - Create a topic branch from where you want to base your work.
-  - This is usually the master branch.
-  - To quickly create a topic branch based on master:
-    `git checkout -b my_contribution master`
-  - Please avoid working directly on the `master` branch.
+  - This is usually the `main` branch.
+  - To quickly create a topic branch based on `main`:
+    `git checkout -b my_contribution main`
+  - Please avoid working directly on the `main` branch.
 - Write code which follows our
   [code style guides](https://developers.librepcb.org/df/d24/doc_code_style_guide.html)
-  and [.editorconfig settings](https://github.com/LibrePCB/LibrePCB/blob/master/.editorconfig).
+  and [.editorconfig settings](https://github.com/LibrePCB/LibrePCB/blob/main/.editorconfig).
   - You can use [clang-format](https://clang.llvm.org/docs/ClangFormat.html) to
     automatically format the code. To format all files at once, just run the
     script [`./dev/format_code.sh`](dev/format_code.sh).
@@ -62,7 +62,7 @@ there are many other ways how to contribute to the LibrePCB project, see
   - This is done by running the binary
     `./build/tests/unittests/librepcb-unittests`.
 - If you like, feel free to add yourself to the
-  [AUTHORS.md](https://github.com/LibrePCB/LibrePCB/blob/master/AUTHORS.md)
+  [AUTHORS.md](https://github.com/LibrePCB/LibrePCB/blob/main/AUTHORS.md)
   file.
 
 ## Submitting Changes

README.md

@@ -6,7 +6,7 @@
 [![Website](https://img.shields.io/badge/Website-librepcb.org-29d682.svg)](https://librepcb.org/)
 [![Docs](https://img.shields.io/badge/Docs-read-yellow.svg)](https://librepcb.org/docs/)
 
-[![Azure Build Status](https://dev.azure.com/LibrePCB/LibrePCB/_apis/build/status/LibrePCB.LibrePCB?branchName=master)](https://dev.azure.com/LibrePCB/LibrePCB/_build/latest?definitionId=2&branchName=master)
+[![Azure Build Status](https://dev.azure.com/LibrePCB/LibrePCB/_apis/build/status/LibrePCB.LibrePCB?branchName=main)](https://dev.azure.com/LibrePCB/LibrePCB/_build/latest?definitionId=2&branchName=main)
 [![OpenSSF Best Practices](https://bestpractices.coreinfrastructure.org/projects/1652/badge)](https://bestpractices.coreinfrastructure.org/projects/1652)
 
 ## About LibrePCB
@@ -37,7 +37,7 @@ For internal details take a look at the
 
 ## Development
 
-***WARNING: The `master` branch always contains the latest UNSTABLE version of
+***WARNING: The `main` branch always contains the latest UNSTABLE version of
 LibrePCB. Everything you do with this unstable version could break your
 workspace, libraries or projects, so you should not use it productively! For
 productive use, please install an official release as described in the
@@ -87,7 +87,7 @@ sudo pacman -S qt5-doc qtcreator # optional
 *Note: Instead of installing the dependencies and building LibrePCB manually,
 you could install the package
 [librepcb-git](https://aur.archlinux.org/packages/librepcb-git/) from the AUR.
-The package clones and builds the latest version of the `master` branch from
+The package clones and builds the latest version of the `main` branch from
 GitHub.*
 
 #### Installation on Mac OS X

ci/build_librepcb.sh

@@ -21,7 +21,7 @@ if [ ! -f ./i18n/librepcb.ts ]; then
   if [ "$OS" = "windows" ]; then  # Workaround for permission error
     git config --global --add safe.directory '*'
   fi
-  git -C ./i18n checkout master && git -C ./i18n pull origin master
+  git -C ./i18n checkout main && git -C ./i18n pull origin main
 fi
 
 # build librepcb

dev/build_each_commit.sh

@@ -18,7 +18,7 @@ if [[ -n $(git status --porcelain) ]]; then
 fi
 echo "STASH=${STASH}"
 
-START="master"
+START="main"
 END=${HEAD}
 
 trap "git checkout ${HEAD} && test ${STASH} -ne 1 || git stash pop" EXIT
@@ -31,4 +31,3 @@ for commit in ${COMMITS[@]}; do
 done
 
 echo "SUCCESSFULLY FINISHED!"
-

dev/doxygen/pages/code_style_guide.md

@@ -19,7 +19,7 @@ This page describes the code style guide for LibrePCB developers.
   command `clang-format -style=file -i <FILE>` to format a single source file.
 - To automatically format all modified source, CMake, *.ui and *.qrc files,
   please run the script `./dev/format_code.sh`. It will format all files which
-  are modified compared to the `master` branch (this avoids formatting of files
+  are modified compared to the `main` branch (this avoids formatting of files
   other than the ones you modified). For details, read the comment in that
   script.
 - If you have Docker installed, it's recommended to invoke that script with

dev/doxygen/pages/developers.md

@@ -4,12 +4,12 @@ General Information for Developers {#doc_developers}
 [TOC]
 
 This page contains some general information for LibrePCB developers. Please also read our
-contribution guidelines: https://github.com/LibrePCB/LibrePCB/blob/master/CONTRIBUTING.md
+contribution guidelines: https://github.com/LibrePCB/LibrePCB/blob/main/CONTRIBUTING.md
 
 
 # Unstable Version {#doc_developers_unstable_versions}
 
-As explained in the @ref doc_release_workflow, the `master` branch is always
+As explained in the @ref doc_release_workflow, the `main` branch is always
 unstable. And unstable doesn't mean "If you have bad luck, something doesn't
 work as expected". It rather means "Everything you save with an unstable
 version can't be opened again with any other (stable or unstable) version!!!".
@@ -33,7 +33,7 @@ to the one above. But be careful with the disabled warning! :)
 
 # Git {#doc_developers_git}
 
-- The `master` branch must always compile and all tests have to pass (CI successful).
+- The `main` branch must always compile and all tests have to pass (CI successful).
 - Use separate branches to fix bugs or implement new features.
 - Do not pack lot of changes in one commit. Make small, incremental commits instead.
 - Write commit messages according this guideline: http://chris.beams.io/posts/git-commit/
@@ -44,9 +44,9 @@ to the one above. But be careful with the disabled warning! :)
 To keep our Git history clear, simple and consistent, we use the following
 strategy for working with branches and GitHub Pull Requests:
 
-- If a branch is outdated (i.e. commits were added to `master` in the mean
+- If a branch is outdated (i.e. commits were added to `main` in the mean
   time), the branch should be updated by **rebasing** it. Please do not update
-  branches by merging `master` into it (as the "Update Branch" button on the
+  branches by merging `main` into it (as the "Update Branch" button on the
   GitHub UI unfortunately does).
 - When adding fixes or other new changes to a branch, the already pushed
   commits should be updated accordingly (e.g. modified or amended) and then

dev/doxygen/pages/mainpage.md

@@ -20,6 +20,6 @@ LibrePCB Developers Documentation {#mainpage}
 
 # External Links {#doc_main_external}
 
-- Contribution Guidelines: https://github.com/LibrePCB/LibrePCB/blob/master/CONTRIBUTING.md
-- Development Resources: https://github.com/LibrePCB/LibrePCB/tree/master/dev
-- Diagrams: https://github.com/LibrePCB/LibrePCB/tree/master/dev/diagrams/svg
+- Contribution Guidelines: https://github.com/LibrePCB/LibrePCB/blob/main/CONTRIBUTING.md
+- Development Resources: https://github.com/LibrePCB/LibrePCB/tree/main/dev
+- Diagrams: https://github.com/LibrePCB/LibrePCB/tree/main/dev/diagrams/svg

dev/doxygen/pages/release_workflow.md

@@ -42,13 +42,13 @@ Whether the file format is stable or not is controlled by the define
 # Git Branches {#doc_release_workflow_branches}
 
 The continuous development happens on feature/bugfix branches (or pull requests),
-which are merged into the `master` branch as soon as they are finished. As new
-features sometimes also introduce file format changes, the `master` branch must
+which are merged into the `main` branch as soon as they are finished. As new
+features sometimes also introduce file format changes, the `main` branch must
 always be considered to contain the (unstable) *next* major version of the
 application. For example if the last stable release was version "2.3.4", the
-`master` must immediately be considered as version "3.0.0-unstable".
+`main` must immediately be considered as version "3.0.0-unstable".
 
-This also means that on the `master` branch we cannot provide updates for
+This also means that on the `main` branch we cannot provide updates for
 already released versions. So we have to provide such updates in release
 branches. For every major version we create a release branch, which is then used
 for *any* update for that major version. For example on the branch `release/2`
@@ -57,7 +57,7 @@ we would provide the releases "2.0", "2.0.1" (bugfix) and "2.1.0" (new feature).
 ![Git Branches](release_workflow_diagram.png)
 
 Features and bugfixes which do not affect the file format may be cherry-picked
-from `master` to release branches. This way we can publish updates for the last
+from `main` to release branches. This way we can publish updates for the last
 officially released application version while the next major version is still in
 development. Generally we do *not* maintain older releases than the last stable
 release because this would be too much effort. So for example as soon as the
@@ -73,7 +73,7 @@ application's version number. Examples: "0.1.0-rc1", "0.1.0", "1.2.0", "1.2.1"
 
 # Warning in Unstable Versions {#doc_release_workflow_warning}
 
-Because (at least) the `master` branch is always unstable, it's very dangerous
+Because (at least) the `main` branch is always unstable, it's very dangerous
 for end users to work productively with this version (it could break projects
 etc.!). So we should warn users in that situation.
 
@@ -89,18 +89,18 @@ released).
 
 We use [Transifex] to translate LibrePCB into other languages. As Transifex
 doesn't have support for branches, we use a separate [resource] for each major
-application version. The translations for the `master` branch are contained in
+application version. The translations for the `main` branch are contained in
 the resource `librepcb.ts`, while translations for releases are contained in
 resources like `librepcb-0.1.ts`.
 
 Translations are automatically checked into the repository
 [LibrePCB/librepcb-i18n](https://github.com/LibrePCB/librepcb-i18n). The
-`master` branch contains translations of the resource `librepcb.ts`, while
+`main` branch contains translations of the resource `librepcb.ts`, while
 translations of resources for releases are available on branches for the
 corresponding releases (e.g. `release/0.1` for `librepcb-0.1.ts`).
 
 The `librepcb-i18n` repository is included as a submodule in the main
-repository. On the `master` branch, the submodule points to a commit which does
+repository. On the `main` branch, the submodule points to a commit which does
 not contain any translation files because translations change very often, so we
 would have to update the submodule very often too (avoid commit spam). But on
 release branches, the submodule points to the translations for the corresponding
@@ -111,7 +111,7 @@ for packagers).
 # Changelog {#doc_release_workflow_changelog}
 
 The changelog is not checked into the repository because it would probably lead
-to confusion (add it to the `master` branch, release branches or even both?).
+to confusion (add it to the `main` branch, release branches or even both?).
 Instead, currently we use our blog to list the changes of every release.
 
 
@@ -132,22 +132,22 @@ downloading translations from [Transifex].
 
 ## Prepare New Major Release
 
-1. Review the file format of the current `master` branch very carefully. We must
+1. Review the file format of the current `main` branch very carefully. We must
    be sure that the file format is completely stable *before* creating a release
    branch.
 2. On [Transifex], create a new [resource] by copying `librepcb.ts`.
-3. Create a new release branch (e.g. `release/0.1`) from the current `master`.
-4. On `master`, add a commit to increment the application's major version and
+3. Create a new release branch (e.g. `release/0.1`) from the current `main`.
+4. On `main`, add a commit to increment the application's major version and
    the file format version.
 5. On the release branch, set the define `FILE_FORMAT_STABLE` to `1` and commit.
 6. On the release branch, change resource in `.tx/config` to the corresponding
    release (e.g. 'librepcb-0.1.ts') and commit.
 
 ## Create Release
 
-1. Make sure CI uses the latest Qt version. If necessary, update CI on `master`
+1. Make sure CI uses the latest Qt version. If necessary, update CI on `main`
    first and test the artifacts before starting with the release procedure.
-2. Cherry-pick relevant commits from `master` to the release branch (e.g.
+2. Cherry-pick relevant commits from `main` to the release branch (e.g.
    `release/0.1`). For minor releases, only pick commits which do not modify
    the file format!
 3. Make sure all submodules point to persistent commits (commits could be
@@ -171,8 +171,8 @@ downloading translations from [Transifex].
     "LibrePCB <LIBREPCB_APP_VERSION>". Keep in mind that the tag must be
     signed and the version number must always have three numbers (i.e. "0.1.0"
     instead of "0.1")!
-13. Cherry-pick the `org.librepcb.LibrePCB.appdata.xml` commit to `master`.
-14. For major releases, bump application and installer version on `master`.
+13. Cherry-pick the `org.librepcb.LibrePCB.appdata.xml` commit to `main`.
+14. For major releases, bump application and installer version on `main`.
 15. Update website/documentation download links and publish blog post
     containing the changelog.
 16. Add tag description to [GitHub Releases], including a link to the blog post.

dev/format_code.sh

@@ -78,8 +78,8 @@ do
   if [ "$ALL" == "--all" ]; then
     TRACKED=$(git ls-files -- "${dir}**.cpp" "${dir}**.hpp" "${dir}**.h")
   else
-    # Only files which differ from the master branch
-    TRACKED=$(git diff --name-only master -- "${dir}**.cpp" "${dir}**.hpp" "${dir}**.h")
+    # Only files which differ from the main branch
+    TRACKED=$(git diff --name-only main -- "${dir}**.cpp" "${dir}**.hpp" "${dir}**.h")
   fi
   UNTRACKED=$(git ls-files --others --exclude-standard -- "${dir}**.cpp" "${dir}**.hpp" "${dir}**.h")
   for file in $TRACKED $UNTRACKED
@@ -118,8 +118,8 @@ do
   if [ "$ALL" == "--all" ]; then
     TRACKED=$(git ls-files -- "${dir}**.ui")
   else
-    # Only files which differ from the master branch
-    TRACKED=$(git diff --name-only master -- "${dir}**.ui")
+    # Only files which differ from the main branch
+    TRACKED=$(git diff --name-only main -- "${dir}**.ui")
   fi
   UNTRACKED=$(git ls-files --others --exclude-standard -- "${dir}**.ui")
   for file in $TRACKED $UNTRACKED
@@ -152,8 +152,8 @@ echo "Formatting CMake files with cmake-format..."
 if [ "$ALL" == "--all" ]; then
   TRACKED=$(git ls-files -- "**CMakeLists.txt" "*.cmake")
 else
-  # Only files which differ from the master branch
-  TRACKED=$(git diff --name-only master -- "**CMakeLists.txt" "*.cmake")
+  # Only files which differ from the main branch
+  TRACKED=$(git diff --name-only main -- "**CMakeLists.txt" "*.cmake")
 fi
 UNTRACKED=$(git ls-files --others --exclude-standard -- "**CMakeLists.txt" "*.cmake")
 for file in $TRACKED $UNTRACKED
@@ -185,8 +185,8 @@ echo "Formatting resource files with xmlsort..."
 if [ "$ALL" == "--all" ]; then
   TRACKED=$(git ls-files -- "**.qrc")
 else
-  # Only files which differ from the master branch
-  TRACKED=$(git diff --name-only master -- "**.qrc")
+  # Only files which differ from the main branch
+  TRACKED=$(git diff --name-only main -- "**.qrc")
 fi
 UNTRACKED=$(git ls-files --others --exclude-standard -- "**.qrc")
 for file in $TRACKED $UNTRACKED

libs/librepcb/core/serialization/fileformatmigrationunstable.h

@@ -43,7 +43,7 @@ class SExpression;
  *
  * This class overrides the stable file format migration class to perform
  * only a partial upgrade. This allows to upgrade file from the previous
- * unstable file format (master branch) to the latest unstable file format
+ * unstable file format (main branch) to the latest unstable file format
  * (feature branch). This upgrade is only performed when the environment
  * variable `LIBREPCB_UPGRADE_UNSTABLE=1` is set.
  */

libs/librepcb/editor/dialogs/aboutdialog.cpp

@@ -109,7 +109,7 @@ AboutDialog::AboutDialog(const WorkspaceSettings& settings,
            "License (GPL) version 3 or later. You can find the full license "
            "text <a href='%1'>in our source code</a>.")
             .arg(
-                "https://github.com/LibrePCB/LibrePCB/blob/master/"
+                "https://github.com/LibrePCB/LibrePCB/blob/main/"
                 "LICENSE.txt") %
         "</p>";
     mUi->lblIntro->setText(text);

tests/cli/conftest.py

@@ -71,7 +71,7 @@ def _env(self):
         # Use a neutral username
         env['USERNAME'] = 'testuser'
         # Disable warning about unstable file format, since tests are run also
-        # on the (unstable) master branch
+        # on the (unstable) main branch
         env['LIBREPCB_DISABLE_UNSTABLE_WARNING'] = '1'
         return env
 

tests/funq/conftest.py

@@ -80,7 +80,7 @@ def __init__(self, config, tmpdir):
         # Force LibrePCB to use Qt-style file dialogs because native dialogs don't work
         self.env['LIBREPCB_DISABLE_NATIVE_DIALOGS'] = '1'
         # Disable warning about unstable file format, since tests are run also
-        # on the (unstable) master branch
+        # on the (unstable) main branch
         self.env['LIBREPCB_DISABLE_UNSTABLE_WARNING'] = '1'
 
     def abspath(self, relpath):