diff --git a/docs/development/supported-versions.md b/docs/development/supported-versions.md index 077328007741..db14aedf7099 100755 --- a/docs/development/supported-versions.md +++ b/docs/development/supported-versions.md @@ -1,50 +1,239 @@ # 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
Jour Fixe
~16 months before"] --> CC["Coding
Completed
~5 months before"] + CC --> BETA["Beta Phase
starts
~4 months before"] + BETA --> REL["RELEASE
March"] + REL --> FS["Full Support
until end of
next year"] + FS --> SEC["Security only
+ 1 more year"] + 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 @@ -52,6 +241,15 @@ 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
security-only phase"] --> B{"Issue in an eligible
status?"} + B -->|no| C["Leave as is"] + B -->|yes| D["Move 'Target Version' to the next
still fully supported version"] + D --> E["Assignee re-checks whether the
issue still exists in maintained versions"] + E --> F["Add a comment informing
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`. @@ -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. \ No newline at end of file +This applies to issues for ILIAS 10 or greater.