|
11 | 11 | 7. If the release was made on a maintenance branch, make sure to `merge` or `cherry-pick` the `CHANGELOG.md` entry to |
12 | 12 | the `main` branch as well. |
13 | 13 |
|
14 | | -## Branching and Release Workflow |
15 | | - |
16 | | -This repository maintains two major versions, supporting Spring Boot 3 and 4. The goal is to maintain both versions at |
17 | | -least until Spring Boot 3 reaches its end of life or becomes irrelevant. |
18 | | - |
19 | | -| branch | info | latest | |
20 | | -|------------------|--------------------------------------------|--------------------------------------------------------------------------------------------------------------------------| |
21 | | -| `main` | version `2.x` supporting Spring Boot `4.x` | [][maven-central] | |
22 | | -| `release-v1.*.x` | version `1.x` supporting Spring Boot `3.x` | [][maven-central] | |
23 | | - |
24 | | -Bugfixes for `1.x` should be merged into the lowest applicable `1.x` release branch. From there, they are cascaded |
25 | | -forward into newer version branches if applicable, so fixes propagate through the release line without being duplicated |
26 | | -unnecessarily. |
27 | | - |
28 | | -Following diagram demonstrates the merge direction that comes from `release-v1.0.x` up to `main`. |
29 | | - |
30 | | -```mermaid |
31 | | -graph LR |
32 | | - A[release-v1.0.x<br/>original bugfix] |
33 | | - A --> B[release-v1.1.x<br/>merge commit with release-v1.0.x] |
34 | | - B --> C[main<br/>merge commit with release-v1.1.x] |
35 | | -``` |
36 | | - |
37 | | -**Note** that the `1.x` major version is supported, but older minor release lines may not be maintained long-term. Bug |
38 | | -fixes are applied only when necessary, and maintenance typically focuses on the more recent `1.*.x` branches unless an |
39 | | -issue is critical or a change can be backported with minimal effort. |
40 | | - |
41 | 14 | ## Maven Central |
42 | 15 |
|
43 | 16 | [][gradle-publish-release] |
|
0 commit comments