Release lines
A release line is a series of versions you keep supporting after a newer one ships, such as
1.5.x beside 2.0, or an LTS. Customers who can't upgrade still ask "is my version safe and
supported?" A line answers from the record: its support dates, its open findings, and the fixes not
yet backported to it.
Why you would use it
You shipped 2.0 last quarter, but three customers are contractually on 1.5 and will be for a year. A vulnerability is announced in a library both versions use. Your team patches 2.x the same day. Now a customer on 1.5 asks two questions: are we affected, and when will we get a fix?
Without a line, the answer lives in someone's memory: which 1.5 release is current, whether its support has ended, whether that library changed between 1.5.2 and 1.5.3, and whether anyone opened the backport. With a line, the 1.5.x page shows its condition from the dates you gave it, its newest release, every finding on that release nobody has decided, and each fix from the main line that has not reached it yet.
When you don't need it
If everyone upgrades to your newest release, you don't need release lines: Logmarq already follows the newest release. Start a line when customers stay on an older version, when you publish an LTS, or when you tag patches on an older series after a newer one has shipped.
How it works in Logmarq
- Membership. A line has a version pattern, such as
v1.5.*. Releases that match it join as they are recorded, and older ones can be added in one step. A release can also be added or taken out by hand. - Condition. A line's status is supported, security fixes only, or end of life, with optional dates for when full support and security fixes end. Its condition today follows from both, so a line whose date has passed moves on even if nobody updated its status. A line with no end date says so rather than guessing one.
- Attention. For the line's newest release, Logmarq lists every finding still undecided or unresolved, with the decision that holds and where it was made, or why none holds, for example a component upgraded since the decision was made on an earlier release. It says whether the scan behind each finding is current, stale, or unknown.
- Backports. A backport need is a linked record: what needs to come across, the vulnerability or change it answers, and a link to where the work happens. It is closed by naming the line's release that carries the fix.
- Maintained. Every project's lines on one page, the ones that need someone first.
What it will not claim
- Logmarq never performs a backport. It records the need and links the work; your team and your git host do the change.
- Decisions do not cross changed components. A decision made on 2.x applies to a 1.5 release only where the same component at the same version ships. A changed component is asked about again.
- Unknown stays unknown. A line release with no bill of materials or no recent scan says so, rather than reading as clean.
- Not yet used by an outside team. Release lines exist in the development build and have not yet been used by a team outside Dekglas.
Get started
On a project's page, start a line with its name, version pattern, and support dates. From the server, the CLI inside the image does the same:
docker exec logmarq logmarq line create <project> 1.5.x --pattern 'v1.5.*' --support-ends <date>
Related pages
VEX: vulnerability decisions · Vulnerability scanning · Environments