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
@@ -9,16 +9,16 @@ Details are described in [a week in the life of a BOM release manager](#a-week-i
9
9
10
10
| Release Date | Lead |
11
11
|--------------| -------------------- |
12
-
| 2025-11-14 | Bruno Verachten |
13
-
| 2025-11-21 | Bruno Verachten |
14
-
| 2025-11-28 | Mark Waite |
15
-
| 2025-12-05 | Mark Waite |
16
-
| 2025-12-12 | Darin Pope |
17
-
| 2025-12-19 | Darin Pope |
18
-
| 2025-12-26 | Adrien Lecharpentier |
19
-
| 2026-01-02 | Adrien Lecharpentier |
20
-
| 2026-01-09 | Kris Stern |
12
+
| 2025-01-02 | Adrien Lecharpentier |
13
+
| 2026-01-09 | Adrien Lecharpentier |
21
14
| 2026-01-16 | Kris Stern |
15
+
| 2026-01-23 | Kris Stern |
16
+
| 2026-01-30 | Bruno Verachten |
17
+
| 2026-02-06 | Bruno Verachten |
18
+
| 2026-02-13 | Mark Waite |
19
+
| 2026-02-20 | Mark Waite |
20
+
| 2026-02-27 | Darin Pope |
21
+
| 2026-03-06 | Darin Pope |
22
22
23
23
## Releasing the BOM
24
24
@@ -86,6 +86,116 @@ Then you can work on the PR. Once done, push your changes back to the PR. If eve
86
86
87
87
There are some known issues that commonly need to be addressed by the BOM release manager.
88
88
89
+
##### Handling Rollbacks
90
+
91
+
Sometimes a dependency update that was merged and released causes compatibility issues or test failures that are discovered before the BOM release. When this happens, a rollback process is needed to temporarily revert the problematic change while the issue is investigated and resolved.
92
+
93
+
###### When to Consider a Rollback
94
+
95
+
A dependency update should be reverted when it results in persistent test failures in the plugin BOM. It is even better if the persistent test failure can be fixed by updating to a newer version of the dependency that fixes the test failure.
96
+
97
+
###### Rollback Process
98
+
99
+
When a problematic dependency update needs to be rolled back, follow these steps:
100
+
101
+
1. Notify the Author
102
+
103
+
**Notify the author of the problematic change as close as possible to the actual problem area.** Leave a comment on the original PR or commit that introduced the issue, explaining the specific problems encountered.
104
+
105
+
Where possible, provide an example that the plugin developer can use to see the problem from within the plugin repository. Most plugin developers are not familiar with maintaining the plugin BOM, so they will struggle with using the plugin BOM repository to duplicate the problem. A plugin developer is more likely to resolve a problem when they can see it with `mvn clean verify` in their plugin repository.
106
+
107
+
**Example:**
108
+
```
109
+
Looks like these changes are causing issues with doing a BOM release
110
+
this week. For reference:
111
+
112
+
tl;dr...two plugins that passed on the Tuesday weekly-test (foo-plugin
113
+
and bar-plugin) are now failing.
114
+
115
+
For the moment so I can get the BOM release out today, I'm going to
116
+
revert the PR that put in github-branch-source 1844.v4a_9883d49126.
117
+
118
+
The local BOM commands I'm running that are failing are:
As noted, when I locally go back to github-branch-source
123
+
1834.v857721ea_74c6 both tests are passing.
124
+
```
125
+
126
+
**Reference:** See [this example notification](https://github.com/jenkinsci/github-branch-source-plugin/pull/822#issuecomment-3238052920) to the plugin author.
127
+
128
+
2. Revert the Change
129
+
130
+
Create a revert commit that rolls back the problematic dependency update. In the commit message and the pull request description, include a link to the notification that was sent to the author.
131
+
132
+
**Example commit message:**
133
+
```
134
+
Revert "chore(deps): bump github-branch-source to 1844.v4a_9883d49126 in /bom-weekly"
135
+
136
+
Rolling back due to compatibility issues with downstream plugins.
137
+
See notification to author: https://github.com/jenkinsci/github-branch-source-plugin/pull/822#issuecomment-3238052920
138
+
```
139
+
140
+
3. Trigger Dependabot
141
+
142
+
Comment `@dependabot rebase` on the reverted PR to trigger Dependabot to reprocess the change.
143
+
144
+
4. Disable Automerge
145
+
146
+
Disable automerge for the PR to prevent it from being automatically merged again while the issue is being investigated.
147
+
148
+
5. Request Changes Review
149
+
150
+
- Click on **"Files changed"** tab in the PR
151
+
- Click **"Review changes"**
152
+
- Select **"Request changes"**
153
+
- Add a comment explaining why changes are requested (reference the compatibility issues)
154
+
- Click **"Submit review"**
155
+
156
+
6. Add `weekly-test` Label
157
+
158
+
Add the `weekly-test` label to the PR to ensure it gets additional testing before being considered for merge again.
159
+
160
+
7. Leave the PR Open
161
+
162
+
Do not close the PR. Leave it open so that:
163
+
- The issue remains visible and can be tracked
164
+
- The author can address the compatibility issues
165
+
- Testing can be re-run once fixes are implemented
166
+
167
+
8. Convert to Draft
168
+
169
+
Convert the PR to draft status by clicking the **"Convert to draft"** link at the bottom of the Reviewers block. This signals that the PR is not ready for merge.
170
+
171
+
###### Example Rollback
172
+
173
+
For a complete example of this rollback process in action, see [BOM PR #5611](https://github.com/jenkinsci/bom/pull/5611), which demonstrates:
174
+
175
+
- Author notification with specific failure details
176
+
- Revert commit with reference to the notification
177
+
- PR converted to draft status
178
+
- Changes requested with clear explanation
179
+
-`weekly-test` label applied
180
+
- Automerge disabled
181
+
182
+
###### After the Rollback
183
+
184
+
Once the rollback is complete:
185
+
186
+
1.**Monitor the Issue**: Keep track of whether the author addresses the compatibility problems
187
+
2.**Re-test When Ready**: Once fixes are implemented, the PR can be converted back from draft and re-tested
188
+
3.**Coordinate Release**: Ensure the fixed version is properly tested before including it in the next BOM release
189
+
190
+
###### Communication
191
+
192
+
When performing rollbacks:
193
+
194
+
- Be clear and specific about the issues encountered
195
+
- Provide helpful details like failing tests or error messages
196
+
- Reference specific versions that work vs. versions that fail
197
+
- Be respectful and collaborative - rollbacks are about maintaining stability, not blame
198
+
89
199
##### Dependency requires Jenkins 2.xxx.y or higher
90
200
91
201
This message shows that a plugin requires a newer Jenkins LTS than one or more of the LTS lines supported by the BOM. Pin the older version to the correct LTS line to resolve the issue. Some pull requests that pin older plugin versions include:
@@ -132,7 +242,7 @@ Alternatively, you can call them from wherever you want, just know that they are
132
242
* on the newly created issue, manually set `Type` to `Task`
133
243
* at the time of writing (2024-10-14), there is no `gh` option to set the Type
134
244
* check the CRON expression to see if the pre-release build will be executed at a time suited for you
135
-
* this can also be used to change when the release happened if you prefer the release to be made on thurday
245
+
* this can also be used to change when the release happened if you prefer the release to be made on Thursday
136
246
* run `./bom-release-issue-complete-task.sh 1`
137
247
* Locally run tests for `warnings-ng` for all current LINEs and weekly
0 commit comments