diff --git a/.github/workflows/fuzz.yml b/.github/workflows/fuzz.yml index 65adad6042..61a71b790a 100644 --- a/.github/workflows/fuzz.yml +++ b/.github/workflows/fuzz.yml @@ -13,7 +13,7 @@ on: workflow_dispatch: # # Enable this and reduce the timeout below to check a PR is working # pull_request: - # branches: [ master ] + # branches: [ main ] jobs: fuzz: diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 275bae5006..ba84958e63 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -7,9 +7,9 @@ env: on: push: - branches: [ master ] + branches: [ main ] pull_request: - branches: [ master ] + branches: [ main ] workflow_dispatch: # Cancel in-progress PR builds if another commit is pushed. diff --git a/CODEOWNERS b/CODEOWNERS index 8b01d4c69f..d328a40f94 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -1,5 +1,5 @@ # Engine changes need to be approved by Zac-HD, as per -# https://github.com/HypothesisWorks/hypothesis/blob/master/guides/review.rst#engine-changes +# https://github.com/HypothesisWorks/hypothesis/blob/main/guides/review.rst#engine-changes /hypothesis-python/src/hypothesis/internal/conjecture/ @DRMacIver @Zac-HD # Changes to the paper also need to be approved by DRMacIver or Zac, as authors diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 107a875f1f..e17fb7a185 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -124,7 +124,7 @@ free to have a read of it in advance and go through it yourself if you'd like to required, but it might speed up the process. Once your pull request has a green build and has passed review, it will be merged to -master fairly promptly. This will immediately trigger a release! Don't be scared. If that +main fairly promptly. This will immediately trigger a release! Don't be scared. If that breaks things, that's our fault not yours - the whole point of this process is to ensure that problems get caught before we merge rather than after. diff --git a/conjecture-rust/Cargo.toml b/conjecture-rust/Cargo.toml index 790faf32ef..41bb23cd3d 100644 --- a/conjecture-rust/Cargo.toml +++ b/conjecture-rust/Cargo.toml @@ -3,7 +3,7 @@ name = "conjecture" version = '0.7.0' authors = ["David R. MacIver "] -homepage = "https://github.com/HypothesisWorks/hypothesis/tree/master/conjecture-rust" +homepage = "https://github.com/HypothesisWorks/hypothesis/tree/main/conjecture-rust" repository = "https://github.com/HypothesisWorks/hypothesis/" keywords = ["testing", "fuzzing", "shrinking", "property-based"] diff --git a/guides/internals.rst b/guides/internals.rst index 126ae2c379..07dc61e73e 100644 --- a/guides/internals.rst +++ b/guides/internals.rst @@ -74,7 +74,7 @@ Useful Files to Know About -------------------------- The code associated with Conjecture lives in -`src/hypothesis/internal/conjecture `_. +`src/hypothesis/internal/conjecture `_. There are a number of files in there, but the most important ones are ``engine.py`` and ``data.py``. ``data.py`` defines the core type that is used to represent test cases, @@ -98,13 +98,13 @@ the `testing guide `_, but there are a couple of areas that it's worth specifically highlighting for making changes to the engine: -The first is `tests/conjecture/ `_, +The first is `tests/conjecture/ `_, which is a set of unit tests designed to put the engine into particular scenarios to exercise specific behaviours, with a goal of achieving 100% coverage on it in isolation (though it currently does not quite achieve that for some specific edge cases. We may fix and enforce this later). The other set of tests that are worth knowing about are the quality tests, -in `tests/quality `_. +in `tests/quality `_. These assert specific hard to satisfy properties about the examples that Hypothesis finds - either their existence, or something about the final shrunk result. diff --git a/guides/review.rst b/guides/review.rst index c9dd09f7f3..cc95da8949 100644 --- a/guides/review.rst +++ b/guides/review.rst @@ -197,7 +197,7 @@ Public API changes must satisfy the following: Bug Fixes ~~~~~~~~~ -1. All bug fixes must come with a test that demonstrates the bug on master and +1. All bug fixes must come with a test that demonstrates the bug on main and which is fixed in this branch. An exception *may* be made here if the submitter can convincingly argue that testing this would be prohibitively difficult. 2. Where possible, a fix that makes it impossible for similar bugs to occur is diff --git a/guides/strategies-that-shrink.rst b/guides/strategies-that-shrink.rst index 6584dec53f..3356dc380c 100644 --- a/guides/strategies-that-shrink.rst +++ b/guides/strategies-that-shrink.rst @@ -140,7 +140,7 @@ object at the same time, again so they can be modified or deleted together. The exact behaviour of the shrinking is a topic of active research and development, so if you are interested in the details we recommend reading -the `internals guide `_ +the `internals guide `_ and the well-commented source code in ``hypothesis.internal.conjecture`` as well as David's ECOOP 2020 paper `Test-Case Reduction via Test-Case Generation: Insights From the Hypothesis Reducer diff --git a/hypothesis-python/README.rst b/hypothesis-python/README.rst index 65419d8b70..f45bcf4b2e 100644 --- a/hypothesis-python/README.rst +++ b/hypothesis-python/README.rst @@ -51,7 +51,7 @@ and a mailing list ` If you want to receive occasional updates about Hypothesis, including useful tips and tricks, there's a `TinyLetter mailing list to sign up for them `_. -If you want to contribute to Hypothesis, `instructions are here `_. +If you want to contribute to Hypothesis, `instructions are here `_. If you want to hear from people who are already using Hypothesis, some of them `have written about it `_. diff --git a/hypothesis-python/docs/conf.py b/hypothesis-python/docs/conf.py index fd29d988ab..e99b92aba0 100644 --- a/hypothesis-python/docs/conf.py +++ b/hypothesis-python/docs/conf.py @@ -46,8 +46,8 @@ source_suffix = ".rst" -# The master toctree document. -master_doc = "index" +# The main toctree document. +main_doc = "index" # General information about the project. project = "Hypothesis" @@ -147,7 +147,7 @@ def setup(app): _repo = "https://github.com/HypothesisWorks/hypothesis/" extlinks = { "commit": (_repo + "commit/%s", "commit %s"), - "gh-file": (_repo + "blob/master/%s", "%s"), + "gh-file": (_repo + "blob/main/%s", "%s"), "gh-link": (_repo + "%s", "%s"), "issue": (_repo + "issues/%s", "issue #%s"), "pull": (_repo + "pull/%s", "pull request #%s"), @@ -176,14 +176,14 @@ def setup(app): latex_elements = {} latex_documents = [ - (master_doc, "Hypothesis.tex", "Hypothesis Documentation", author, "manual") + (main_doc, "Hypothesis.tex", "Hypothesis Documentation", author, "manual") ] -man_pages = [(master_doc, "hypothesis", "Hypothesis Documentation", [author], 1)] +man_pages = [(main_doc, "hypothesis", "Hypothesis Documentation", [author], 1)] texinfo_documents = [ ( - master_doc, + main_doc, "Hypothesis", "Hypothesis Documentation", author, diff --git a/hypothesis-python/docs/development.rst b/hypothesis-python/docs/development.rst index 05a24d4edd..3c3d151a62 100644 --- a/hypothesis-python/docs/development.rst +++ b/hypothesis-python/docs/development.rst @@ -38,7 +38,7 @@ If you want to detect this, you can We use continuous deployment to ensure that you can always use our newest and shiniest features - every change to the source tree is automatically built and -published on PyPI as soon as it's merged onto master, after code review and +published on PyPI as soon as it's merged onto main, after code review and passing our extensive test suite. diff --git a/hypothesis-python/docs/packaging.rst b/hypothesis-python/docs/packaging.rst index f9442c24ee..fb25c6628e 100644 --- a/hypothesis-python/docs/packaging.rst +++ b/hypothesis-python/docs/packaging.rst @@ -67,7 +67,7 @@ If you want to test Hypothesis as part of your packaging you will probably not w Hypothesis itself uses for running its tests, because it has a lot of logic for installing and testing against different versions of Python. -The tests must be run with fairly recent tooling; check the :gh-link:`tree/master/requirements/` +The tests must be run with fairly recent tooling; check the :gh-link:`tree/main/requirements/` directory for details. The organisation of the tests is described in the :gh-file:`hypothesis-python/tests/README.rst`. diff --git a/hypothesis-python/setup.py b/hypothesis-python/setup.py index 83e2079338..31432cdbe7 100644 --- a/hypothesis-python/setup.py +++ b/hypothesis-python/setup.py @@ -85,7 +85,7 @@ def local_file(name): package_data={"hypothesis": ["py.typed", "vendor/tlds-alpha-by-domain.txt"]}, url="https://hypothesis.works", project_urls={ - "Source": "https://github.com/HypothesisWorks/hypothesis/tree/master/hypothesis-python", + "Source": "https://github.com/HypothesisWorks/hypothesis/tree/main/hypothesis-python", "Changelog": "https://hypothesis.readthedocs.io/en/latest/changes.html", "Documentation": "https://hypothesis.readthedocs.io", "Issues": "https://github.com/HypothesisWorks/hypothesis/issues", diff --git a/hypothesis-ruby/hypothesis-specs.gemspec b/hypothesis-ruby/hypothesis-specs.gemspec index c00a98788d..0c4b238759 100644 --- a/hypothesis-ruby/hypothesis-specs.gemspec +++ b/hypothesis-ruby/hypothesis-specs.gemspec @@ -14,7 +14,7 @@ DESCRIPTION 'Cargo.toml', 'LICENSE.txt', 'README.markdown', 'Rakefile', 'CHANGELOG.md' ] - s.homepage = 'https://github.com/HypothesisWorks/hypothesis/tree/master/hypothesis-ruby' + s.homepage = 'https://github.com/HypothesisWorks/hypothesis/tree/main/hypothesis-ruby' s.license = 'MPL-2.0' s.extensions = Dir['ext/extconf.rb'] s.add_dependency 'rutie', '~> 0.0.3' diff --git a/tooling/setup.py b/tooling/setup.py index 3f84ed61f2..a104a54ca9 100644 --- a/tooling/setup.py +++ b/tooling/setup.py @@ -28,7 +28,7 @@ def local_file(name): author_email="david@drmaciver.com", packages=setuptools.find_packages(SOURCE), package_dir={"": SOURCE}, - url="https://github.com/HypothesisWorks/hypothesis-python/tree/master/tooling", + url="https://github.com/HypothesisWorks/hypothesis-python/tree/main/tooling", license="MPL v2", description="A library for property-based testing", python_requires=">=3.7", diff --git a/tooling/src/hypothesistooling/__init__.py b/tooling/src/hypothesistooling/__init__.py index 158cb44629..31d7801765 100644 --- a/tooling/src/hypothesistooling/__init__.py +++ b/tooling/src/hypothesistooling/__init__.py @@ -55,7 +55,7 @@ def merge_base(a, b): def point_of_divergence(): - return merge_base("HEAD", "origin/master") + return merge_base("HEAD", "origin/main") def has_changes(files): @@ -105,7 +105,7 @@ def create_tag(tagname): def push_tag(tagname): assert_can_release() subprocess.check_call(["git", "push", "origin", shlex.quote(tagname)]) - subprocess.check_call(["git", "push", "origin", "HEAD:master"]) + subprocess.check_call(["git", "push", "origin", "HEAD:main"]) def assert_can_release(): @@ -143,10 +143,10 @@ def all_files(): ] -def changed_files_from_master(): - """Returns a list of files which have changed between a branch and master.""" +def changed_files_from_main(): + """Returns a list of files which have changed between a branch and main.""" files = set() - command = ["git", "diff", "--name-only", "HEAD", "master"] + command = ["git", "diff", "--name-only", "HEAD", "main"] diff_output = subprocess.check_output(command).decode("ascii") for line in diff_output.splitlines(): filepath = line.strip() diff --git a/tooling/src/hypothesistooling/__main__.py b/tooling/src/hypothesistooling/__main__.py index 48fbd3e626..3c98bd2e02 100644 --- a/tooling/src/hypothesistooling/__main__.py +++ b/tooling/src/hypothesistooling/__main__.py @@ -110,13 +110,13 @@ def do_release(package): @task() def deploy(): HEAD = tools.hash_for_name("HEAD") - MASTER = tools.hash_for_name("origin/master") + MAIN = tools.hash_for_name("origin/main") print("Current head: ", HEAD) - print("Current master:", MASTER) + print("Current main:", MAIN) - if not tools.is_ancestor(HEAD, MASTER): - print("Not deploying due to not being on master") + if not tools.is_ancestor(HEAD, MAIN): + print("Not deploying due to not being on main") sys.exit(0) if "TWINE_PASSWORD" not in os.environ: diff --git a/website/content/2016-04-19-rule-based-stateful-testing.md b/website/content/2016-04-19-rule-based-stateful-testing.md index 8a2c009178..671d835d9b 100644 --- a/website/content/2016-04-19-rule-based-stateful-testing.md +++ b/website/content/2016-04-19-rule-based-stateful-testing.md @@ -337,9 +337,9 @@ This feature is currently somewhat under-documented so hasn't seen as widespread it could. However, there are at least two interesting real world examples: 1. Hypothesis uses it to test itself. Hypothesis has [tests of its example database]( - https://github.com/HypothesisWorks/hypothesis-python/blob/master/tests/cover/test_database_agreement.py) + https://github.com/HypothesisWorks/hypothesis-python/blob/main/tests/cover/test_database_agreement.py) which work very much like the above, and [a small model of its test API]( - https://github.com/HypothesisWorks/hypothesis-python/blob/master/tests/nocover/test_strategy_state.py) + https://github.com/HypothesisWorks/hypothesis-python/blob/main/tests/nocover/test_strategy_state.py) which generates random strategies and runs tests using them. 2. It's being used to [test Mercurial](https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-February/080037.html) generating random. So far it's found [bug 5112](https://bz.mercurial-scm.org/show_bug.cgi?id=5112) and diff --git a/website/content/2016-04-29-testing-performance-optimizations.md b/website/content/2016-04-29-testing-performance-optimizations.md index 522c1ca818..79ada7e925 100644 --- a/website/content/2016-04-29-testing-performance-optimizations.md +++ b/website/content/2016-04-29-testing-performance-optimizations.md @@ -124,4 +124,4 @@ This technique combines especially well with [Hypothesis's stateful testing](../rule-based-stateful-testing/), because you can use it to then test different implementations of complex APIs. For example, Hypothesis uses this property together with stateful testing to [verify that the different implementations of its example database -behave identically](https://github.com/HypothesisWorks/hypothesis/blob/master/hypothesis-python/tests/nocover/test_database_agreement.py). +behave identically](https://github.com/HypothesisWorks/hypothesis/blob/main/hypothesis-python/tests/nocover/test_database_agreement.py). diff --git a/website/content/2016-05-31-looking-for-guest-posts.md b/website/content/2016-05-31-looking-for-guest-posts.md index 9293fd2c6a..32fd3b0434 100644 --- a/website/content/2016-05-31-looking-for-guest-posts.md +++ b/website/content/2016-05-31-looking-for-guest-posts.md @@ -16,7 +16,7 @@ Details of how to guest post on here: 1. This site is [a Jekyll site on GitHub](https://github.com/HypothesisWorks/HypothesisWorks.github.io). To add a post, create a markdown file in the _posts directory with the appropriate structure and send a pull request. -2. You will want to add an entry for yourself to [the authors data file](https://github.com/HypothesisWorks/HypothesisWorks.github.io/blob/master/_data/authors.yml) +2. You will want to add an entry for yourself to [the authors data file](https://github.com/HypothesisWorks/HypothesisWorks.github.io/blob/main/_data/authors.yml) 3. You of course retain all copyright to your work. All you're granting is the right to publish it on this site. I'd particularly like to hear from: diff --git a/website/content/2016-06-05-incremental-property-based-testing.md b/website/content/2016-06-05-incremental-property-based-testing.md index 5e292c34eb..0ba88ecb8a 100644 --- a/website/content/2016-06-05-incremental-property-based-testing.md +++ b/website/content/2016-06-05-incremental-property-based-testing.md @@ -25,20 +25,20 @@ List branches: $ tlr branch foo - * master + * main Switch to an existing branch: $ tlr checkout foo * foo - master + main Create a branch and switch to it: $ tlr checkout -b new-branch $ tlr branch foo - master + main * new-branch Early on, my colleague and I found a bug: when you created a new branch with @@ -48,10 +48,10 @@ this: $ tlr checkout -b new-branch $ tlr branch foo - * master + * main new-branch -The previously active branch (in this case, `master`) stayed active, rather +The previously active branch (in this case, `main`) stayed active, rather than switching to the newly-created branch (`new-branch`). Before we fixed the bug, we decided to write a test. I thought this would be a @@ -204,8 +204,8 @@ Adding edge cases ----------------- There's one valid branch name that this strategy *could* generate, but -probably won't: `master`. If we left the test just as it is, then one time in -a hojillion the strategy would generate `"master"` and the test would fail. +probably won't: `main`. If we left the test just as it is, then one time in +a hojillion the strategy would generate `"main"` and the test would fail. Rather than waiting on chance, we encoded this in the `valid_branch_names` strategy, to make it more likely: @@ -214,11 +214,11 @@ strategy, to make it more likely: def valid_branch_names(): return st.text(alphabet=letters, min_size=1, max_size=112).map( lambda t: t.lower() - ) | st.just("master") + ) | st.just("main") ``` When we ran the tests now, they failed with an exception due to the branch -`master` already existing. To fix this, we used `assume`: +`main` already existing. To fix this, we used `assume`: ```python from hypothesis import assume @@ -226,7 +226,7 @@ from hypothesis import assume @given(branch_name=valid_branch_names()) def test_checkout_new_branch(self, branch_name): - assume(branch_name != "master") + assume(branch_name != "main") tmpdir = FilePath(self.mktemp()) tmpdir.makedirs() repo = Repository.initialize(tmpdir.path) @@ -234,11 +234,11 @@ def test_checkout_new_branch(self, branch_name): self.assertEqual(branch_name, repo.get_active_branch()) ``` -Why did we add `master` to the valid branch names if we were just going to +Why did we add `main` to the valid branch names if we were just going to exclude it anyway? Because when other tests say "give me a valid branch name", -we want *them* to make the decision about whether `master` is appropriate or +we want *them* to make the decision about whether `main` is appropriate or not. Any future test author will be compelled to actually think about whether -handling `master` is a thing that they want to do. That's one of the great +handling `main` is a thing that they want to do. That's one of the great benefits of Hypothesis: it's like having a rigorous design critic in your team. diff --git a/website/content/2017-09-14-multi-bug-discovery.md b/website/content/2017-09-14-multi-bug-discovery.md index 52a49e5b74..531ddc9984 100644 --- a/website/content/2017-09-14-multi-bug-discovery.md +++ b/website/content/2017-09-14-multi-bug-discovery.md @@ -180,7 +180,7 @@ avoiding slipping to new errors all together. Zac pushed back with some good que around whether this was really the correct thing to do, and after some experimentation and feedback I eventually hit on the design that lead to displaying all of the errors. -Our [review handbook](https://github.com/HypothesisWorks/hypothesis-python/blob/master/guides/review.rst) +Our [review handbook](https://github.com/HypothesisWorks/hypothesis-python/blob/main/guides/review.rst) emphasises that code review is a collaborative design process, and I feel this was a particularly good example of that. We've created a great culture of code review, and we're reaping the benefits (and if you want to get in on it, we could always diff --git a/website/content/2018-02-27-continuous-releases.md b/website/content/2018-02-27-continuous-releases.md index cccd599757..4bb5fd8a4d 100644 --- a/website/content/2018-02-27-continuous-releases.md +++ b/website/content/2018-02-27-continuous-releases.md @@ -21,7 +21,7 @@ In this post, I'll explain how our continuous releases work, and why we find it In the past, Hypothesis was released manually. Somebody had to write a changelog, tag a new release on GitHub, and run some manual pip commands to publish a new version to PyPI -- and only David had the credentials for the latter. -This meant that releases were infrequent, and features spent a long time in master before they were available to `pip install`. +This meant that releases were infrequent, and features spent a long time in main before they were available to `pip install`. The pace of development picked up in 2017 -- partly as new maintainers arrived, and partly groundwork for [David's upcoming (now started) PhD][phd] -- and we wanted to be able to release more frequently. We decided to automate the entire release process. @@ -44,7 +44,7 @@ If you need a release file but haven't written one, the tests fail and your pull Sometimes we write a release file even if there aren't changes to the core code, but we think it's worth a release anyway. For example, changes to the installation code in `setup.py`, or larger changes to our test code for the benefit of downstream packagers. -Once you've written a release file and the pull request is merged into master, and after all the other tests have passed, our CI uses this file to create a new release. +Once you've written a release file and the pull request is merged into main, and after all the other tests have passed, our CI uses this file to create a new release. First, it works out the new version number, and updates it in [version.py][version.py]. Then it copies the release description into the changelog, including the new version number and the current date. @@ -65,7 +65,7 @@ The tag and the commit are pushed to GitHub, and then CI builds a new package an So with no very little extra work, every code change triggers a new release, and it's usually available within half an hour of merging the pull request. This exact system might not scale to larger teams. -In particular, you can't merge new features until the code in master has been released -- you get conflicts around `RELEASE.rst` -- so you can only merge one pull request at a time. +In particular, you can't merge new features until the code in main has been released -- you get conflicts around `RELEASE.rst` -- so you can only merge one pull request at a time. And in Hypothesis, we never backport bugfixes to old major or minor releases -- you'd need some changes to support that. But Hypothesis only has one full-time contributor, and everybody else works on it in their free time, we don't create patches fast enough for this to be a problem. @@ -75,7 +75,7 @@ For us, it works exceptionally well. [recent]: https://github.com/HypothesisWorks/hypothesis-python/pull/1101 [semver]: https://semver.org/ [typo]: https://github.com/HypothesisWorks/hypothesis-python/pull/1069 -[version.py]: https://github.com/HypothesisWorks/hypothesis-python/blob/master/src/hypothesis/version.py +[version.py]: https://github.com/HypothesisWorks/hypothesis-python/blob/main/src/hypothesis/version.py ## Why bother? @@ -102,11 +102,11 @@ If you submit a patch that gets accepted, your change is available immediately, This may less of tangible benefit, but it gives off nice fuzzy feelings, especially if it's your first patch. (Speaking of which, we're always looking [for new contributors][contributors]!) -[contributors]: https://github.com/HypothesisWorks/hypothesis-python/blob/master/CONTRIBUTING.rst +[contributors]: https://github.com/HypothesisWorks/hypothesis-python/blob/main/CONTRIBUTING.rst ## I'm ruined for everything else -I've become used to code being available almost immediately after it's merged into master -- which isn't true for the vast majority of projects. +I've become used to code being available almost immediately after it's merged into main -- which isn't true for the vast majority of projects. When I go to a repo with a bug report, see that a bugfix was merged two weeks ago, but there's yet to be a new release, it's hard not to feel a little impatient. I've started using this in my other repos -- both these scripts exactly, and derivatives of the same idea. @@ -116,4 +116,4 @@ Look in the [scripts directory][scripts] of the main repo. In particular, `check-release-file.py` looks for a release note on pull requests, and `deploy.py` is what actually cuts the release. The code will probably need tweaking for your repo (it's closely based on the Hypothesis repo), but hopefully it provides a useful starting point. -[scripts]: https://github.com/HypothesisWorks/hypothesis-python/tree/master/scripts +[scripts]: https://github.com/HypothesisWorks/hypothesis-python/tree/main/scripts