Document backport branches and auto update #81
Conversation
Vincinator
force-pushed
the
doc/backports-and-auto-updates
branch
from
7aed23a to
b66763b
Compare
Vincinator
force-pushed
the
doc/backports-and-auto-updates
branch
from
99ed0b8 to
aadd6e4
Compare
There was a problem hiding this comment.
Many comments, mostly nitpicks, thanks for taking care @Vincinator
| Any kernel version that we need to maintain other than the latest LTS in main, are maintained in `maint-<MAJOR.MINOR>` branches (e.g. maint-6.6). | ||
| Actual backport releases need to branch of from the respective `maint-<MAJOR.MINOR>` branch and include the corresponding `.container` file for target backport. | ||
|
|
||
| Branches containing the `.container` file must be named according to the `rel-MAJOR` naming scheme (e.g. rel-1443). |
There was a problem hiding this comment.
not sure if we should explain what the .container file does here. I think this is not the right place, but it might be confusing to people who are unaware of our package build. Not sure if we have proper docs we can link here.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
ahhh - Misinterpreted you comment. Fully agree, we need to document .container somewhere - have not found it either.
Sorry, running low on coffee .
|
|
||
|
|
||
| > [!Note] | ||
| > We must create rel- branches to include the respective `.container` file, and not use maint for backports. This is required because multiple releases can use the same kernel version (e.g. rel-1443 and rel-1592 both use maint-6.6) |
There was a problem hiding this comment.
would you think this diagram could be helpful here? not sure if that makes it more clear, what I'm trying to show here is how the branches relate.. left our 'main' branches that always build with the latest env, and right is nightly (no special branch) and our releases (rel branches with .container file)
flowchart LR
A[main branch] --> B(Garden Linux nightly)
A[main branch] --> F(Garden Linux 18xx, TBD)
C[maint-6.6 branch] --> D(rel-1443 branch, Garden Linux 1443)
C[maint-6.6 branch] --> E(rel-1592 branch, Garden Linux 1592)
There was a problem hiding this comment.
Maybe we can make it more generic
| Branch | Description | Release Builds | Example |
|---|---|---|---|
| main branch | Builds kernel version for Garden Linux today's MAJOR.0 via nightly | Garden Linux nightly | - |
| maint-X.Y branch | Keeps sources for Linux X.Y on latest patch level | - | maint-6.6 |
| rel-MAJOR branches | Based on maint-X.Y, used for backport builds of Linux X.Y for Garden Linux MAJOR | Backport builds of Linux X.Y for Garden Linux MAJOR | - rel-1443 uses maint-6.6 - rel-1592 uses maint-6.6 - rel-18XX uses maint-6.12 |
There was a problem hiding this comment.
yes I think this table is helpful
Co-authored-by: Florian Wilhelm <[email protected]>
Co-authored-by: Florian Wilhelm <[email protected]>
Co-authored-by: Florian Wilhelm <[email protected]>
Co-authored-by: Florian Wilhelm <[email protected]>
What this PR does / why we need it:
maint-X.YbranchesRelated #47