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: DEV_WORKFLOW.md
+24-10Lines changed: 24 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,29 +11,41 @@
11
11
Make a milestone related to a release on possibly a minor release schedule (e.g. monthly schedule). Differentiate between the different types of releases (minor, major, patch).
12
12
13
13
## 2. **Git Workflow Branching Model (Made with**[**mermaid**](https://mermaid.js.org)**)**
14
-

14
+

15
15
16
16
***main**: Stores official release history with tagged version numbers (see top row in the diagram above).
17
17
18
18
***develop**: This branch is the integration branch for features.
19
19
20
-
***feature**: Branch off of develop for new feature development. Features get merged to develop (never to main).
20
+
***feature**: Branch off of `develop` for new feature development. Features get merged to `develop` (never to main).
21
21
22
22
***bug**: For fixing specific bugs introduced during the production phase.
23
23
24
-
***hotfix**: Quickly corrects bugs in the latest release version; branched off main.
24
+
***hotfix**: Quickly corrects bugs in the latest release version; branched off `main`.
25
+
26
+
***release/vX.Y.Z**: Temporary branch created from `develop`; used to:
27
+
* Collect Scriv changelog fragments here.
28
+
* Apply final QA or documentation updates.
29
+
* Merge into `main` when ready and tag the release.
25
30
26
31
27
32
## 3. **New Branch naming conventions**
28
33
29
34
30
35
Branches created for the purpose of a Pull Request should be directly related to an open issue within the project’s issue tracker. This ensures that all code changes are tied to specific tasks or features, facilitating better organisation and tracking of contributions. Below are the branch naming conventions:
- Replace `<ISSUE_NUMBER>` with the tracker issue number.
47
+
- Keep short-description concise.
48
+
- Release branches are short-lived and should not include ongoing development.
37
49
38
50
39
51
Replace with the corresponding issue number and provide a brief description of the changes in \`short\_description\`.
@@ -43,7 +55,7 @@ Replace with the corresponding issue number and provide a brief description of t
43
55
44
56
* Pull the latest changes from the remote repository
45
57
46
-
* Checkout develop
58
+
* Checkout `develop`
47
59
48
60
* Create a new feature branch
49
61
@@ -57,7 +69,7 @@ Replace with the corresponding issue number and provide a brief description of t
57
69
58
70
* Run training and metrics validation tests locally to confirm no breaking behaviour or errors were introduced. Include test reports as per the PR template.
59
71
60
-
* Open a Pull Request to start the review process, ensuring to map the branch correctly to the target branch (i.e. feature\_branch -> develop or hotfix\_branch -> main).
72
+
* Open a Pull Request to start the review process, ensuring to map the branch correctly to the target branch (i.e. `feature` -> `develop` or `hotfix` -> `main`).
61
73
62
74
* In the description of the Pull Request, explicitly state whether the PR resolves or closes an open issue by using one of the following formats:
63
75
@@ -77,7 +89,6 @@ Example: "Solves #12345" or "Closes #8679".
77
89
78
90
## 6. **Merging Pull Requests**
79
91
80
-
81
92
* Approval and Merging: Once the reviewer approves the PR and all feedback is addressed, merge the feature branch into develop. Note, it is the reviewer who is responsible for merging the PR when satisfied with the changes.
82
93
83
94
## 7. **Changelog and release notes**
@@ -100,6 +111,9 @@ This approach:
100
111
```bash
101
112
scriv create
102
113
```
114
+
**Notes**:
115
+
- Do not collect fragments in your PR; leave [Unreleased] in CHANGELOG.md.
116
+
-[Unreleased] is always at the top; contributors never write directly into it.
103
117
104
118
Fragment creation and writing guidelines are documented in [CONTRIBUTING.md](./CONTRIBUTING.md).
105
119
@@ -114,7 +128,7 @@ This separation keeps release notes accurate and enables clean backports
114
128
115
129
* Each milestone targets a release (feature, patch, etc).
116
130
117
-
* Open a PR from develop to main upon completing a milestone
131
+
* Open a PR from `develop` to `release/vX.Y.Z` upon completing a milestone
118
132
119
133
* Collect changelog fragments and generate release notes using:
0 commit comments