@@ -108,25 +108,25 @@ report the bug or propose the feature you'd like to add.
108
108
It's best to create a new, separate branch for each piece of work you want to do. E.g.::
109
109
110
110
git fetch upstream
111
- git checkout -b shiny-new-feature upstream/master
111
+ git checkout -b shiny-new-feature upstream/main
112
112
113
113
This changes your working directory to the 'shiny-new-feature' branch. Keep any changes in
114
114
this branch specific to one bug or feature so it is clear what the branch brings to
115
115
NumCodecs.
116
116
117
117
To update this branch with latest code from NumCodecs, you can retrieve the changes from
118
- the master branch and perform a rebase::
118
+ the main branch and perform a rebase::
119
119
120
120
git fetch upstream
121
- git rebase upstream/master
121
+ git rebase upstream/main
122
122
123
- This will replay your commits on top of the latest NumCodecs git master . If this leads to
123
+ This will replay your commits on top of the latest NumCodecs git main . If this leads to
124
124
merge conflicts, these need to be resolved before submitting a pull request.
125
- Alternatively, you can merge the changes in from upstream/master instead of rebasing,
125
+ Alternatively, you can merge the changes in from upstream/main instead of rebasing,
126
126
which can be simpler::
127
127
128
128
git fetch upstream
129
- git merge upstream/master
129
+ git merge upstream/main
130
130
131
131
Again, any conflicts need to be resolved before submitting a pull request.
132
132
@@ -183,7 +183,7 @@ Documentation
183
183
~~~~~~~~~~~~~
184
184
185
185
Docstrings for user-facing classes and functions should follow the `numpydoc
186
- <https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt > `_ standard,
186
+ <https://numpydoc.readthedocs.io/en/latest/format.html#docstring-standard > `_ standard,
187
187
including sections for Parameters and Examples. All examples will be run as doctests
188
188
under Python 3.9.
189
189
@@ -213,7 +213,7 @@ one core developers before being merged. Ideally, pull requests submitted by a c
213
213
should be reviewed and approved by at least one other core developers before being merged.
214
214
215
215
Pull requests should not be merged until all CI checks have passed (Travis, AppVeyor,
216
- Coveralls) against code that has had the latest master merged in.
216
+ Coveralls) against code that has had the latest main merged in.
217
217
218
218
Compatibility and versioning policies
219
219
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -290,9 +290,9 @@ compatibility in some way.
290
290
Release procedure
291
291
~~~~~~~~~~~~~~~~~
292
292
293
- Checkout and update the master branch::
293
+ Checkout and update the main branch::
294
294
295
- $ git checkout master
295
+ $ git checkout main
296
296
$ git pull
297
297
298
298
Verify all tests pass on all supported Python versions, and docs build::
0 commit comments