You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ArviZ uses the following process to cut a new release of the library.
3
+
ArviZ uses the following process to cut a new release of the ArviZverse packages.
4
4
5
-
1. Bump the version number in `arviz/__init__.py`
5
+
1. Bump the version number in `src/<arviz repo>/__init__.py` or `src/<arviz repo>/_version.py`
6
6
7
7
```diff
8
-
- __version = "0.12.0"
9
-
+ __version = "0.12.1"
8
+
- __version = "1.2.0"
9
+
+ __version = "1.2.1"
10
10
```
11
11
12
-
2. Update the release notes in `CHANGELOG.md`. Remove any subsections within the released version
13
-
without any items within them.
12
+
2. Check versions in `pyproject.toml`. Arviz aims to follow the recommendations in [SPEC-0](https://scientific-python.org/specs/spec-0000/) from scientific python.
14
13
15
-
```diff
16
-
- ## v0.x.x Unreleased
17
-
+ ## v0.12.1 (2022 May 12)
18
-
```
19
-
20
-
Empty subheadings for the "unreleased" development version don't need to be included yet.
21
-
22
-
3. Check versions in `requirements.txt` and `setup.py` files. Arviz aims to follow the recommendations in [SPEC-0](https://scientific-python.org/specs/spec-0000/) from scientific python.
14
+
3. Open a Pull Request including these changes. Make sure all CI tests pass, adding commits if necessary.
15
+
Even if CI is passing on main, there might be new releases of dependencies that break CI.
23
16
24
-
4. Open a Pull Request including these changes. Make sure all CI tests pass, adding commits if necessary. Even if CI is passing on main, there might be new releases of dependencies that break CI.
17
+
:::{important}
18
+
The documentation build should also complete successfully. If we publish a release from a commit
19
+
where the docs don't build we then have to choose between that version not showing in the
20
+
version switcher or publishing a patch release that fixes the doc build.
21
+
:::
25
22
26
-
5. Add a release in the Github [release page](https://github.com/arviz-devs/arviz/releases) once the PR is merged.
23
+
4. Add a release in the Github [release page](https://github.com/arviz-devs/arviz/releases) once the PR is merged.
27
24
28
-
6. After the release on Github, the CI system will complete the rest of the steps. Including making any wheels and uploading the new version to PyPI.
25
+
5. After the release on Github, the CI system will complete the rest of the steps. Including making any wheels and uploading the new version to PyPI.
26
+
It will also add a PR to update the changelog.
29
27
30
-
7. Add a follow-up PR changing the version string to include the dev flag.
28
+
6. Add a follow-up PR changing the version string to include the dev flag.
31
29
Make sure the version string is [PEP 440](https://peps.python.org/pep-0440/#appendix-b-parsing-version-strings-with-regular-expressions) compliant.
32
30
For example, after releasing `v0.12.1` it should be set to `0.13.0.dev0`.
33
31
34
-
8. Use the following template to add empty subheadings to the `CHANGELOG.md` file in the follow-up PR.
35
-
36
-
```markdown
37
-
## v0.x.x Unreleased
38
-
39
-
### New features
40
-
41
-
### Maintenance and fixes
42
-
43
-
### Deprecation
44
-
45
-
### Documentation
46
-
```
47
-
48
-
9. If the versions were updated in step 3, update also the [conda forge recipe](https://github.com/conda-forge/arviz-feedstock).
32
+
7. If the versions were updated in step 3, update also the [conda forge recipe](https://github.com/conda-forge/arviz-feedstock).
49
33
50
34
:::{important}
51
35
There is a bot that opens a PR automatically to update the conda forge recipe.
52
-
However, **all dependencies must be checked manually**to ensure the ones in
53
-
the recipe match those in the requirements
36
+
There is a second bot that also attempts to update dependecies automatically from `pyproject.toml`,
37
+
however, at the time of writing it is experimental, so we always need to double check dependencies.
54
38
:::
55
39
56
-
10. (here for reference but we really want to avoid it) If for some reason there were an issue
57
-
with a release, there are two tools to fix it in conda forge:
40
+
8. (here for reference but we really want to avoid it) If for some reason there were an issue
41
+
with a release, there are two tools to fix it in conda forge:
58
42
59
-
* repodata patch: If there is a new release for one of the dependencies with breaking changes
60
-
for example, a repodata patch should be submitted to conda forge to prevent users
61
-
from installing a broken environment.
43
+
* repodata patch: If there is a new release for one of the dependencies with breaking changes
44
+
for example, a repodata patch should be submitted to conda forge to prevent users
45
+
from installing a broken environment.
62
46
63
-
Repodata patches are submitted to [conda-forge/conda-forge-repodata-patches-feedstock](https://github.com/conda-forge/conda-forge-repodata-patches-feedstock)
64
-
* mark a build as broken: If the dependencies were incorrect in the recipe, then the existing
65
-
build should be marked as broken and a PR (completely manual) should be submitted
66
-
to the arviz-feedstock to fix the recipe. Note that if this is being done for a release
67
-
different than the latest, changes should not be merged into `main` but on a dedicated
68
-
branch, the conda-forge package build is generated all the same but the history is kept
69
-
tidier and prevents issues when a new release is published.
47
+
Repodata patches are submitted to [conda-forge/conda-forge-repodata-patches-feedstock](https://github.com/conda-forge/conda-forge-repodata-patches-feedstock)
48
+
* mark a build as broken: If the dependencies were incorrect in the recipe, then the existing
49
+
build should be marked as broken and a PR (completely manual) should be submitted
50
+
to the arviz-feedstock to fix the recipe. Note that if this is being done for a release
51
+
different than the latest, changes should not be merged into `main` but on a dedicated
52
+
branch, the conda-forge package build is generated all the same but the history is kept
53
+
tidier and prevents issues when a new release is published.
70
54
71
-
Requests to mark packages as broken are submitted to [conda-forge/admin-requests](https://github.com/conda-forge/admin-requests/)
55
+
Requests to mark packages as broken are submitted to [conda-forge/admin-requests](https://github.com/conda-forge/admin-requests/)
1. Fork the [project repository](https://github.com/arviz-devs/arviz/) by clicking on the 'Fork' button near the top right of the main repository page. This creates a copy of the code under your GitHub user account.
19
+
:::{admonition} Have you already gone through this tutorial?
20
+
:class: dropdown tip
21
+
22
+
If this is not your first time going over this tutorial and you want to
23
+
work on your 2nd+ PR you can skip steps 1-3, and instead do:
24
+
25
+
```bash
26
+
git checkout main
27
+
git fetch upstream
28
+
git rebase upstream/main
29
+
```
30
+
31
+
This will make sure you are on the `main` branch of your local repository and sync it
32
+
with the one on GitHub. After this you can continue with {ref}`step 4 <feature_branch_step_pr>`
33
+
to create your feature branch from the up-to-date `main`
34
+
:::
35
+
36
+
1. Fork the project repository by clicking on the 'Fork' button near the top right of the main repository page. This creates a copy of the code under your GitHub user account.
12
37
13
38
(fork_step_pr)=
14
-
2. Clone your fork of the ArviZ repo from your GitHub account to your local disk.
39
+
2. Clone your fork of the target ArviZ repository from your GitHub account to your local disk.
@@ -66,28 +91,59 @@ clone it to your local machine, and develop on a feature branch.
66
91
67
92
```{warning}
68
93
Always create a new ``feature`` branch before making any changes. Make your changes
69
-
in the ``feature`` branch. It's good practice to never routinely work on the ``main`` branch of any repository.
94
+
in the ``feature`` branch. It's good practice to never routinely work on the ``main`` branch of any repository
95
+
and we have a pre-commit check that prevents committing to `main`
70
96
```
71
97
72
-
5. Project requirements are defined in pyproject.toml. Libraries used for development and documentation are provided as optional dependency groups. To set up a development environment, you may (probably in a [virtual environment](https://docs.python-guide.org/dev/virtualenvs/)) run:
98
+
5. We use [tox](https://tox.wiki/en/latest/index.html) to help with common development tasks.
99
+
To get your development environment up and running we recommend installing `tox` and the
100
+
arviz local package you are working on:
73
101
74
102
```bash
103
+
pip install tox
75
104
pip install -e .
76
-
pip install -e .[test,check]
77
-
pip install -e .[doc] # to generate docs locally
78
105
```
79
106
80
-
Alternatively, for developing the project in [Docker](https://docs.docker.com/), there is a script to setup the Docker environment for development. See {ref}`developing_in_docker`.
107
+
6. Work on your feature, bugfix, documentation improvement...
81
108
82
-
6. Develop the feature on your feature branch. Add your changes using git commands, ``git add`` and then ``git commit``, like:
109
+
7. Execute the relevant development related tasks. Each repository has slightly different needs
110
+
for testing or doc building so we start by checking the available tox commands:
111
+
112
+
```bash
113
+
tox list -m dev
114
+
```
115
+
116
+
which will print something like:
117
+
118
+
```none
119
+
check -> Perform style checks
120
+
docs -> Build HTML docs
121
+
test-namespace -> Run ArviZ metapackage tests
122
+
cleandocs -> Clean HTML doc build outputs
123
+
viewdocs -> View HTML docs with the default browser
124
+
```
125
+
126
+
we then execute the relevant commands. If we have been working a bugfix and didn't
127
+
change anything related to documentation we can skip those tasks and run only the
128
+
`check` and `test-namespace` ones:
129
+
130
+
```bash
131
+
tox -e test-namespace
132
+
tox -e check
133
+
```
134
+
135
+
(commit_push_step_pr)=
136
+
6. Once you are happy with the changes, add your changes using git commands,
137
+
``git add`` and then ``git commit``, like:
83
138
84
139
```bash
85
140
git add modified_files
86
141
git commit -m "commit message here"
87
142
```
88
143
89
-
to record your changes locally.
90
-
After committing, it is a good idea to sync with the base repository in case there have been any changes:
144
+
to record your changes locally. After committing, it is a good idea to sync with the base
145
+
repository in case there have been any changes:
146
+
91
147
```bash
92
148
git fetch upstream
93
149
git rebase upstream/main
@@ -99,8 +155,18 @@ clone it to your local machine, and develop on a feature branch.
99
155
git push -u origin my-feature
100
156
```
101
157
102
-
7. Go to the GitHub web page of your fork of the ArviZ repo. Click the 'Pull request' button to send your changes to the project's maintainers for review. This will send an email to the committers.
158
+
7. Go to the GitHub web page of the respective ArviZ repository you were working on.
159
+
Click the 'Pull request' button to send your changes to the project's maintainers for review.
160
+
This will send an email to the committers.
103
161
104
162
:::{tip}
105
163
Now that the PR is ready to submit, check the {ref}`pr_checklist`.
106
164
:::
165
+
166
+
8. Thanks for contributing! {octicon}`heart-fill` Now Wait for reviews to come it.
167
+
Most reviewers work on ArviZ on a volunteer basis, depending on availability and
168
+
workload it can take several days until you get a review.
169
+
170
+
9. Address review comments. Some PRs can be merged directly, but the most common scenario
171
+
if for further commits to be needed. To update your PR you only need to commit to the
172
+
same branch you were working on and push as shown in {ref}`step 6 <commit_push_step_pr>`.
0 commit comments