Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rename the master branch to main #1352

Closed
drvinceknight opened this issue Jun 15, 2020 · 3 comments
Closed

Rename the master branch to main #1352

drvinceknight opened this issue Jun 15, 2020 · 3 comments

Comments

@drvinceknight
Copy link
Member

I would like to rename the master branch to main.

(There's a tool here that helps with this: https://github.com/mheap/github-default-branch)
@marcharper
Copy link
Member

Maybe this is a good time to reconsider the branches "officially". main isn't particularly meaningful from a development standpoint -- is it the main working branch? the current release?

How about a structure such as:

  • release in which the HEAD is the most current tagged release
  • dev or develop which is the "development stable" (i.e. all tests pass) but not yet released, sort of a staging branch I guess
  • people can have other auxiliary branches as needed before merging into dev (e.g. the current ultimatum branch)

When we want to do new releases we just merge dev into release and tag it. New PRs go into dev by default. WDYT?

Next, I'm not sure we need to grant access to a tool for this -- we just push a new branch and tell github that's the new default, right? AFAIK git doesn't have a concept of a default branch (unless that's changed recently), so we just need to set the github default in settings (and delete the old branch).

Also, maybe we want to revisit the contributing instructions and provide a command to setup a venv with the right defaults / dependencies. Seems like we'll need to at least document how people should open PRs and the meaning of the branch names.

@drvinceknight
Copy link
Member Author

How about a structure such as:

  • release in which the HEAD is the most current tagged release
  • dev or develop which is the "development stable" (i.e. all tests pass) but not yet released, sort of a staging branch I guess
  • people can have other auxiliary branches as needed before merging into dev (e.g. the current ultimatum branch)

When we want to do new releases we just merge dev into release and tag it. New PRs go into dev by default. WDYT?

That sounds great and makes the release process more straightforward.

Next, I'm not sure we need to grant access to a tool for this -- we just push a new branch and tell github that's the new default, right? AFAIK git doesn't have a concept of a default branch (unless that's changed recently), so we just need to set the github default in settings (and delete the old branch).

I assumed the tool would take care of any PRs that might be up so that they would automatically "redirect" to the new branch but I'm happy to not use it and just figure out whatever is broken as and when (it won't be anything hard to fix).

Also, maybe we want to revisit the contributing instructions and provide a command to setup a venv with the right defaults / dependencies. Seems like we'll need to at least document how people should open PRs and the meaning of the branch names.

Yeah great call. This could be the first PR to dev 👍

drvinceknight added a commit that referenced this issue Aug 12, 2020
@drvinceknight
Write a new documentation page with branch info
76cefeb 
This is related to #1352.

Once this PR is merged we should:

- Change github default branch to `dev`
- Delete `master`
- Confirm that read the docs is looking at `release`

Am I missing anything?

We should also remove the release process information from the wiki
(assuming we're happy with what I've written here).

Finally, once #1360 is done we should make sure we update the docs with
the relevant information.
This was referenced Aug 12, 2020
Merged
Closed
Nikoleta-v3 pushed a commit that referenced this issue Sep 9, 2020
@drvinceknight
Write a new documentation page with branch info (#1367)
7cbe2d7 
* Write a new documentation page with branch info

This is related to #1352.

Once this PR is merged we should:

- Change github default branch to `dev`
- Delete `master`
- Confirm that read the docs is looking at `release`

Am I missing anything?

We should also remove the release process information from the wiki
(assuming we're happy with what I've written here).

Finally, once #1360 is done we should make sure we update the docs with
the relevant information.

* Remove ambiguous `very`.

* Remove hypothesis version specification in docs.

This is actually no longer correct since #1288

* Test properties not affected by floating point error

This build found a particular failing example of
`TestTournament.test_seeding_equality` https://github.com/Axelrod-Python/Axelrod/pull/1368/checks?check_run_id=975415322

Upon closer investigation it looks like that was not due to seeding but
due to the floating point error of some calculations made by the result
set.

I investigated using:

```
import axelrod as axl
import numpy as np

seed = 2
repetitions = 10
rng = axl.RandomGenerator(seed=seed)
players = [axl.Random(rng.random()) for _ in range(8)]
tournament1 = axl.Tournament(
    players=players,
    turns=10,
    repetitions=repetitions,
    seed=seed
)
tournament2 = axl.Tournament(
    players=players,
    turns=10,
    repetitions=repetitions,
    seed=seed
)
for _ in range(4):
    results1 = tournament1.play(processes=2, progress_bar=False)
    results2 = tournament2.play(processes=2, progress_bar=False)
    assert results1.wins == results2.wins
    assert results1.match_lengths == results2.match_lengths
    assert results1.scores == results2.scores
    assert np.allclose(results1.normalised_scores, results2.normalised_scores)
    assert np.allclose(results1.ranking, results2.ranking)
    assert results1.ranked_names == results2.ranked_names
    assert results1.payoffs == results2.payoffs
    assert results1.payoff_matrix == results2.payoff_matrix
    assert np.allclose(results1.payoff_stddevs, results2.payoff_stddevs)
    assert results1.score_diffs == results2.score_diffs
    assert results1.payoff_diffs_means == results2.payoff_diffs_means
    assert results1.cooperation == results2.cooperation
    assert results1.normalised_cooperation == results2.normalised_cooperation
    assert results1.vengeful_cooperation == results2.vengeful_cooperation
    assert results1.cooperating_rating == results2.cooperating_rating
    assert results1.good_partner_matrix == results2.good_partner_matrix
    assert results1.good_partner_rating == results2.good_partner_rating
    assert np.allclose(results1.eigenmoses_rating, results2.eigenmoses_rating)
    assert np.allclose(results1.eigenjesus_rating, results2.eigenjesus_rating)
```

Note I'm using `np.isclose` for some properties.

In this commit:

- I add the specific seed for which the error was found as a hypothesis
  example (`seed=2`).
- Replace the `results1 == results2` check with just a check of some
  properties (from which the others are essentially calculated).
- Added `progress_bar=False`

* Add instructions for using venv.

* s/requirements/requirements.txt

* Spell requirements correctly..
@drvinceknight
Copy link
Member Author

This has been closed by #1372, I have also set the default branch on GitHub to be dev.

@drvinceknight drvinceknight mentioned this issue Sep 30, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@marcharper @drvinceknight