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: docs/development/release-checklist.md
+40-7
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,12 @@
1
1
# Release Checklist
2
2
3
-
This documentation describes the process of packaging and publishing a new NetBox release. There are three types of release:
3
+
This documentation describes the process of packaging and publishing a new NetBox release. There are three types of releases:
4
4
5
5
* Major release (e.g. v3.7.8 to v4.0.0)
6
6
* Minor release (e.g. v4.0.10 to v4.1.0)
7
7
* Patch release (e.g. v4.1.0 to v4.1.1)
8
8
9
-
While major releases generally introduce some very substantial change to the application, they are typically treated the same as minor version increments for the purpose of release packaging.
9
+
While major releases generally introduce some very substantial changes to the application, they are typically treated the same as minor version increments for the purpose of release packaging.
10
10
11
11
For patch releases (e.g. upgrading from v4.2.2 to v4.2.3), begin at the [patch releases](#patch-releases) heading below. For minor or major releases, complete the entire checklist.
12
12
@@ -31,6 +31,29 @@ Close the [release milestone](https://github.com/netbox-community/netbox/milesto
31
31
32
32
Check that a link to the release notes for the new version is present in the navigation menu (defined in `mkdocs.yml`), and that a summary of all major new features has been added to `docs/index.md`.
33
33
34
+
### Update the Dependency Requirements Matrix
35
+
36
+
For every minor release, update the dependency requirements matrix in `docs/installation/upgrading.md` ("All versions") to reflect the supported versions of Python, PostgreSQL, and Redis:
37
+
38
+
1. Add a new row with the supported dependency versions.
39
+
2. Include a documentation link using the release tag format: `https://github.com/netbox-community/netbox/blob/v4.2.0/docs/installation/index.md`
40
+
3. Bold any version changes for clarity.
41
+
42
+
**Example Update:**
43
+
44
+
```markdown
45
+
| NetBox Version | Python min | Python max | PostgreSQL min | Redis min | Documentation |
If a new Django release is adopted or other major dependencies (Python, PostgreSQL, Redis) change:
53
+
54
+
* Update the installation guide (`docs/installation/index.md`) with the new minimum versions.
55
+
* Update the upgrade guide (`docs/installation/upgrading.md`) for the current version accordingly.
56
+
34
57
### Manually Perform a New Install
35
58
36
59
Start the documentation server and navigate to the current version of the installation docs:
@@ -39,15 +62,25 @@ Start the documentation server and navigate to the current version of the instal
39
62
mkdocs serve
40
63
```
41
64
42
-
Follow these instructions to perform a new installation of NetBox in a temporary environment. This process must not be automated: The goal of this step is to catch any errors or omissions in the documentation, and ensure that it is kept up-to-date for each release. Make any necessary changes to the documentation before proceeding with the release.
65
+
Follow these instructions to perform a new installation of NetBox in a temporary environment. This process must not be automated: The goal of this step is to catch any errors or omissions in the documentation and ensure that it is kept up to date for each release. Make any necessary changes to the documentation before proceeding with the release.
43
66
44
67
### Test Upgrade Paths
45
68
46
-
Upgrading from a previous version typically involves database migrations, which must work without errors. Supported upgrade paths include from one minor version to another within the same major version (i.e. 4.0 to 4.1), as well as from the latest patch version of the previous minor version (i.e. 3.7 to 4.0 or to 4.1). Prior to release, test all these supported paths by loading demo data from the source version and performing a `./manage.py migrate`.
69
+
Upgrading from a previous version typically involves database migrations, which must work without errors.
70
+
Test the following supported upgrade paths:
71
+
72
+
- From one minor version to another within the same major version (e.g. 4.0 to 4.1).
73
+
- From the latest patch version of the previous minor version (e.g. 3.7 to 4.0 or 4.1).
74
+
75
+
Prior to release, test all these supported paths by loading demo data from the source version and performing:
76
+
77
+
```no-highlight
78
+
./manage.py migrate
79
+
```
47
80
48
81
### Merge the `feature` Branch
49
82
50
-
Submit a pull request to merge the `feature` branch into the `main` branch in preparation for its release. Once it has been merged, continue with the section for patch releases below.
83
+
Submit a pull request to merge the `feature` branch into the `main` branch in preparation for its release. Once it has been merged, continue with the section for the patch releases below.
51
84
52
85
### Rebuild Demo Data (After Release)
53
86
@@ -59,7 +92,7 @@ After the release of a new minor version, generate a new demo data snapshot comp
59
92
60
93
### Create a Release Branch
61
94
62
-
Begin by creating a new branch (based off of`main`) to effect the release. This will comprise the changes listed below.
95
+
Begin by creating a new branch (based on`main`) to effect the release. This will comprise the changes listed below.
63
96
64
97
```
65
98
git checkout main
@@ -136,7 +169,7 @@ Then, compile these portable (`.po`) files for use in the application:
136
169
* Add a section for this release at the top of the changelog page for the minor version (e.g. `docs/release-notes/version-4.2.md`) listing all relevant changes made in this release.
137
170
138
171
!!! tip
139
-
Put yourself in the shoes of the user when recording change notes. Focus on the effect that each change has for the end user, rather than the specific bits of code that were modified in a PR. Ensure that each message conveys meaning absent context of the initial feature request or bug report. Remember to include key words or phrases (such as exception names) that can be easily searched.
172
+
Put yourself in the shoes of the user when recording change notes. Focus on the effect that each change has for the end user, rather than the specific bits of code that were modified in a PR. Ensure that each message conveys meaning absent context of the initial feature request or bug report. Remember to include keywords or phrases (such as exception names) that can be easily searched.
0 commit comments