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
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/software_release.md
+12-5Lines changed: 12 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,26 +13,33 @@ assignees: ''
13
13
14
14
### prep release candidate for acceptance testing
15
15
16
-
-[ ] Update the version number to the appropriate release candidate number (e.g., `0.5rc1`)
16
+
-[ ] Update the version number in `src/remarx/__init__.py`to the appropriate release candidate number (e.g., `0.5rc1`)
17
17
-[ ] Create a draft PR (since it should not be merged)
18
18
-[ ] Review the changelog to make sure that all features, changes, bugfixes, etc included in the release are documented. You may want to review the git revision history to be sure you've captured everything.
19
19
-[ ] Review the README to make sure that its contents are up to date
20
20
-[ ] Check python requirements for any internal dependencies that should be released (or at least pinned to a specific git commit)
21
21
-[ ] Confirm that all checks for the draft PR pass (e.g., unit tests, code coverage checks)
22
-
-[ ]Review code documentation to make sure it is up to date.
22
+
-[ ]Build documentation on the release branch and run the server to review and make sure it is up to date.
23
23
24
-
### acceptance testing fails
24
+
### BEFORE acceptance testing
25
+
26
+
-[ ] Review issues included in the release to make sure they have testing instructions before marking them as ready for acceptance testing.
27
+
-[ ] Give project team members instructions about how to install the release candidate version.
28
+
29
+
### IF acceptance testing fails
30
+
31
+
*These steps are only needed if acceptance testing fails and you need to update and retest the release candidate.*
25
32
26
33
-[ ] Increment the version number to the next release candidate (e.g., `0.5rc1` → `0.5rc2`)
27
34
-[ ] Address the changes raised in acceptance testing and repeat the previous section.
28
35
29
-
### acceptance testing passes
36
+
### WHEN acceptance testing passes
30
37
31
38
-[ ] Set the final release version number (e.g., `0.5rc1` → `0.5`)
32
39
-[ ] Use git flow to finish the release (merge release branch into both main and develop, create a tag, remove the release branch, etc.). (`git flow release finish 0.5`)
33
40
34
41
## after release
35
42
36
-
-[ ] Increase the develop branch version so it is set to the next expected release (i.e., if you just released `0.5` then develop will probably be `0.6-dev` unless you are working on a major update, in which case it will be `1.0-dev`)
43
+
-[ ] Increase the develop branch version so it is set to the next expected release (i.e., if you just released `0.5` then develop will probably be `0.6.dev0` unless you are working on a major update, in which case it will be `1.0.dev0`)
37
44
-[ ] Push all updates to GitHub (main branch, develop branch, tags)
38
45
-[ ] Create a GitHub release for the new tag, to trigger package publication on PyPI (and eventually Zenodo DOI)
0 commit comments