Skip to content

[Docs] Rewrite and expand supported versions policy #11740

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mjansenDatabay wants to merge 1 commit into
base: trunk
Choose a base branch
from
+244 −46
Open

[Docs] Rewrite and expand supported versions policy #11740

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
290 changes: 244 additions & 46 deletions docs/development/supported-versions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,57 +1,255 @@
# Supported Versions

Every ILIAS version will be **fully supported** until the end of the year after
the year it was released in. **Fully supported** means that every kind of issue
that is reported for the release according to our bugfixing process is eligible
for a fix. *E.g.: A usability issue, reported for ILIAS 10 (released 2025), can
be reported in August 2026 and is eligible for a fix then.*

Every ILIAS version will then gain **security support** for an additional year
after that. **Security support** means that we are fixing security issues only.
*E.g.: A security issue, reported for ILIAS 10 (release 2025), can be reported
in August 2027 and is eligible for a fix then. A malfunction that does make the
program crash, reported at the same moment, won't be eligible for a fix.*


## Timeline per Version

With that support schedule, every version will have (roughly) the following timeline:

| Date | ILIAS X | ILIAS (X+1) | ILIAS (X+2) |
|-----------|-------------------------|-------------------------|-------------------------|
| 20X4, Nov | Project Jour Fixe | | |
| 20X5, Oct | Coding Completed | | |
| 20X5, Nov | Start of Beta Phase | Project Jour Fixe | |
| 20X6, Mar | Release | | |
| 20X6, Oct | | Coding Completed | |
| 20X6, Nov | | Start of Beta Phase | Project Jour Fixe |
| 20X7, Mar | | Release | |
| 20X7, Oct | | | Coding Completed |
| 20X7, Dec | End of Full Support | | Start of Beta Phase |
| 20X8, Mar | | | Release |
| 20X8, Dec | End of Security Support | End of Full Support | |
| 20X9, Dec | | End of Security Support | End of Full Support |
| 20Y0, Dec | | | End of Security Support |


## Implications

* If we follow this optimal timeline, users have roughly 3/4 year to update to the
next fully supported version. This can be expanded to 1 3/4 year if users skip
every other fully supported version.
* From the project planning jour fixe to the end of security support, every version is
active for a little more then four years.
* Most of the time, the community will need to keep track of four different version
in different states of their life cycle.
* Most of the changes that fix issues will need to be included in three branches,
fixes for security issues will need to be included in four branches.
> **In a nutshell**
> A new ILIAS version is released roughly every year (usually in spring).
> After its release, each version goes through **two support phases**:
>
> 1. **Full support** – *every* reported issue may be fixed
> (bugs, usability problems, security problems …).
> 2. **Security support** – *only security* issues are fixed.
>
> A simple rule of thumb:
> **Full support covers the release year plus the following year; after that
> comes one more year of security-only support.**
> Then the version reaches its end of life.

This document explains the exact rules, shows how several versions overlap over
time, and summarises what it means for the different people who work with ILIAS.


## How long is a version supported?

The two phases are defined precisely as follows:

| Phase | Lasts until … | What gets fixed |
|-----------------------|----------------------------------------------------------|------------------------------------------|
| **Full support** | the **end of the year *after* the release year** | any kind of issue (bug, usability, security …) |
| **Security support** | the **end of the following year** (one more year) | security issues **only** |
| **End of life** | after security support ends | nothing – please upgrade |

**Examples (ILIAS 10, released in 2025):**

* A **usability** issue reported in **August 2026** *is* eligible for a fix –
ILIAS 10 is still in **full support** (until the end of 2026).
* A **security** issue reported in **August 2027** *is* eligible for a fix –
ILIAS 10 is then in **security support** (until the end of 2027).
* A **crash / malfunction** reported in **August 2027** is **not** eligible –
in the security phase only security issues are fixed.


## The life cycle of a single version

Every version passes through the same milestones. The months below are given
**relative to its release** (releases usually happen in **March**):

```mermaid
flowchart LR
JF["Project<br/>Jour Fixe<br/><i>~16 months before</i>"] --> CC["Coding<br/>Completed<br/><i>~5 months before</i>"]
CC --> BETA["Beta Phase<br/>starts<br/><i>~4 months before</i>"]
BETA --> REL["RELEASE<br/><i>March</i>"]
REL --> FS["Full Support<br/><i>until end of<br/>next year</i>"]
FS --> SEC["Security only<br/><i>+ 1 more year</i>"]
SEC --> EOL["End of Life"]

style REL fill:#2e7d32,color:#fff
style FS fill:#1565c0,color:#fff
style SEC fill:#c62828,color:#fff
style EOL fill:#616161,color:#fff
```

| Milestone | When (relative to release) | Meaning |
|-------------------------|----------------------------|------------------------------------------------------|
| Project Jour Fixe | ~16 months before release | Planning of the version starts |
| Coding Completed | ~5 months before release | No new features are added; stabilisation begins |
| Start of Beta Phase | ~4 months before release | Testable pre-release available |
| **Release** | **month 0 (March)** | Full support starts |
| End of Full Support | December of *release year + 1* | Switch to security-only support |
| End of Security Support | December of *release year + 2* | End of life |

From the first planning meeting to the end of security support, a version stays
active for **a little more than four years**.

### How consecutive versions overlap

A new version is already being planned and built while the previous one is still
supported, so **several life cycles run in parallel**. The table below is the
classic overview, but with concrete example versions instead of abstract
placeholders. It follows **ILIAS 12, 13 and 14** through every milestone.
Read it **top to bottom for time**; **each column is one version**
*(months are illustrative — the pattern repeats for every version)*:

| When | ILIAS 12 | ILIAS 13 | ILIAS 14 |
|------------|--------------------------|--------------------------|--------------------------|
| 2025, Nov | Project Jour Fixe | | |
| 2026, Oct | Coding Completed | | |
| 2026, Nov | Start of Beta Phase | Project Jour Fixe | |
| 2027, Mar | **Release** | | |
| 2027, Oct | | Coding Completed | |
| 2027, Nov | | Start of Beta Phase | Project Jour Fixe |
| 2028, Mar | | **Release** | |
| 2028, Oct | | | Coding Completed |
| 2028, Nov | | | Start of Beta Phase |
| 2028, Dec | End of Full Support | | |
| 2029, Mar | | | **Release** |
| 2029, Dec | End of Security Support | End of Full Support | |
| 2030, Dec | | End of Security Support | End of Full Support |
| 2031, Dec | | | End of Security Support |

### Which version is in which phase each year

The same information, but viewed **per calendar year** — this is usually the
question administrators and project managers actually ask: *"What is supported
**this** year?"*

| Year | ILIAS 12 | ILIAS 13 | ILIAS 14 |
|------|-------------------|-------------------|-------------------|
| 2026 | Beta (from Nov) | – | – |
| 2027 | **Full support** | Beta (from Nov) | – |
| 2028 | **Full support** | **Full support** | Beta (from Nov) |
| 2029 | Security only | **Full support** | **Full support** |
| 2030 | End of life | Security only | **Full support** |
| 2031 | End of life | End of life | Security only |

Reading a single row shows the recurring pattern: in a typical year there are
**two versions in full support** plus **one older version in security-only
support**. For example, in **2029** both ILIAS 13 and ILIAS 14 are fully
supported, while ILIAS 12 only receives security fixes.


## Concrete example with real versions

To avoid abstract placeholders, here is how consecutive versions line up on the
calendar. *(Exact dates are illustrative; the binding rule is the two-phase
definition above.)*

| Version | Released | Full support until | Security support until |
|-----------|----------|--------------------|------------------------|
| ILIAS 12 | 2027 | end of **2028** | end of **2029** |
| ILIAS 13 | 2028 | end of **2029** | end of **2030** |
| ILIAS 14 | 2029 | end of **2030** | end of **2031** |
| ILIAS 15 | 2030 | end of **2031** | end of **2032** |

Because the phases overlap, **several versions are supported at the same time**.
The Gantt chart below makes this visible — read it top to bottom (versions) and
left to right (years):

```mermaid
gantt
title ILIAS Support Phases Over Time (illustrative)
dateFormat YYYY-MM-DD
axisFormat %Y

section ILIAS 12
Beta :done, 2026-11-01, 2027-03-01
Full support :active, 2027-03-01, 2028-12-31
Security only :crit, 2029-01-01, 2029-12-31

section ILIAS 13
Beta :done, 2027-11-01, 2028-03-01
Full support :active, 2028-03-01, 2029-12-31
Security only :crit, 2030-01-01, 2030-12-31

section ILIAS 14
Beta :done, 2028-11-01, 2029-03-01
Full support :active, 2029-03-01, 2030-12-31
Security only :crit, 2031-01-01, 2031-12-31

section ILIAS 15
Beta :done, 2029-11-01, 2030-03-01
Full support :active, 2030-03-01, 2031-12-31
Security only :crit, 2032-01-01, 2032-12-31
```

**Legend:** grey = beta / pre-release · blue = full support · red = security
only. Draw an imaginary vertical line at any year and you will usually cross
**two versions in full support** and **one version in security-only support**.


## What this means for you

Two very different groups work with these support phases. **Authorities** build
and safeguard ILIAS itself; **Users** run and operate ILIAS in their
organisations. Each group cares about a different part of the cycle.

### Authorities (Code, Concept, Test Case Curation, Security)

These are the roles responsible for *producing* and *safeguarding* the software.
Their key concern is **into how many versions a change has to flow**.

* **Code (maintainers / developers)**
* A normal bug fix typically has to be applied to **three branches** — trunk
plus the **two fully supported versions**.
* Write fixes so they can be cleanly back-ported across these branches.

* **Concept (product & feature planning)**
* Plan features around the milestones of the *upcoming* version — from
*Project Jour Fixe* to *Coding Completed* (see the life-cycle chapter).

* **Test Case Curation**
* You decide which scenarios, workflows and edge cases must be covered before a
release can be considered safe. Your test cases should reflect what
institutions actually do with ILIAS — not only what developers build.
* The **Beta Phase** (from ~November before the March release) is when your
curated test cases matter most: new and changed behaviour is available for
verification, but the release is not yet final.

* **Security**
* A security fix has the widest reach: it typically has to be applied to
**four branches** — trunk plus the two fully supported versions **plus** the
version that is still in security-only support.
* Security is the *only* kind of fix that a version keeps receiving after it
has left full support.

### Users (Organisation Administrators, Help Desk, Domain Experts)

These are the roles that *operate* ILIAS at an institution and support its
day-to-day use. Their key concern is **which version to run and when to upgrade**.

* **Organisation administrators (system operations)**
* You have roughly **¾ of a year** to move to the next fully supported version
before your current one leaves full support.
* If you upgrade only every *other* version, you still stay within full
support, but your planning runway across two cycles shrinks to about
**1¾ years**.
* Once a version is **security only**, plan the upgrade — normal bugs will no
longer be fixed. After end of life, upgrade as soon as possible.

* **Help Desk / support staff**
* Before promising/requesting a fix, check the version's phase:
* **Full support** → any issue may be fixed.
* **Security only** → only security issues are fixed; other reports are
moved to a still fully supported version (see below).
* **End of life** → the user must upgrade.

* **Domain experts of institutions**
* You design and run e-learning scenarios (courses, assessments, collaboration
workflows …) and often depend on **new ILIAS features** to realise them.
* New features appear in the **upcoming release** — first in beta, then in the
March release. Plan your scenarios around that rhythm: what you need may not
exist in your current version yet.
* If you stay on an older version (especially one in **security-only**
support), you will **not** receive new features — only security fixes. To
use new capabilities, your institution must upgrade to a fully supported
version.
* Use the beta phase to try out whether a planned scenario works with the new
features before your institution upgrades.


## Transition to Security Support

When a version transitions from **full support** to **security support**
(at the end of the year), open issues in the Mantis bug tracker for this version
are handled as follows to ensure that reported problems are not lost:

```mermaid
flowchart TD
A["Version enters<br/>security-only phase"] --> B{"Issue in an eligible<br/>status?"}
B -->|no| C["Leave as is"]
B -->|yes| D["Move 'Target Version' to the next<br/>still fully supported version"]
D --> E["Assignee re-checks whether the<br/>issue still exists in maintained versions"]
E --> F["Add a comment informing<br/>the reporter"]
```

1. **Eligibility for Transition**: All issues with the following status are
considered: `open`, `unassigned`, `feedback`, `needs JF decision`,
`postponed`, `funding needed`, `assigned`, `fixing acc to prio`.
Expand All @@ -68,4 +266,4 @@ are handled as follows to ensure that reported problems are not lost:
entered the security-fix-only phase. We have moved this issue to the next
maintained version for further investigation."

This applies to issues for ILIAS 10 or greater.
This applies to issues for ILIAS 10 or greater.
Loading