Setup - Introduce Strict Update Paths

1 Initial Problem

Currently, administrators expect to be able to update ILIAS from any version to any others. Historically, this is something that ILIAS has indeed promised per default. There were some special occassions where we did indeed require an update to some specific version before updating to later versions, but these cases have been rare and required some special and careful communication.

This situation is indeed comfortable for administrators, but burdens our codebase with the requirement to carry old code with us ad infinitum. This is most visible in the folder `Services/Migration`, where code from very old migration is moved along into the future. But a similar problem could exist or be introduced in other components as well, if components made some significant migration in the past. That is, by supporting updates from any to any version , we will be piling up code from old versions, that can virtually never go away.

The piles of old code are bad on their own, but the very fact that our code, updates and migrations, needs to support a virtually unlimited amount of different pathes for migrations adds another burden on the maintainers, be it when writing code, be it when looking into bug reports.

The additional burden, on the other hand, on administrators that need to update installations is neglibile since the automated setup has been introduced. If someone wants to update, say, from 6 to 8, he needs to first checkout 7, run the setup, then checkout 8 and run the setup again. Since the setup runs on its own without administrators needing to click anything on a GUI, the additional step should not add much work.

2 Conceptual Summary

The update policy of ILIAS is changed in the aforemtioned way. Installations on a Version x.y kann only update to (x+1).y but not (x+2).y etc. First and foremost, this is a matter of communication. Administrators need to be made aware of that change in policy. Thus, the info should be repeated on conferences, meetings of user groups, in the release notes, ...

Second, we suggest to introduce a mechanism into the ILIAS setup that refuses to perform an update that does not match the new policy. If an administrator wants to update an installation on version x.y to (x+2).y, he will be displayed an error message that states the problem and advises him to make the update to the desired version stepwise.

3 User Interface Modifications

3.1 List of Affected Views

none

3.2 User Interface Details

none

3.3 New User Interface Concepts

none

4 Technical Information

This will allow maintainers to get rid of old code in their components.

5 Privacy Information

No privacy implications.

6 Security Implications

No security implications.

7 Contact

• Author of the Request Klees, Richard [rklees]
• Maintainer: Klees, Richard [rklees]
• Implementation of the feature is done by: CaT ILIAS Team

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

Schmid, Fabian [fschmid], 28 APR 2021: I fully support this feature request! Of course this is a trade-off between benefits for administrators and benefits for developers, but from my point of view the ILIAS product will benefit greatly if we introduce this update policy. Thank you Richard for the suggestion!

Seeland, Per Pascal [PerPascalSeeland], 19 May 2021: I also suggest this approach. I would even define that e.g. to be able to upgrade to 8 you would need to have a 7.x with the version at least available at the date when the trunk was cut. This will minimize the amount of changes that need to be tested between two versions. During development, there should be way to override this safe guard by placing a magic file inside the setup.

JourFixe, ILIAS [jourfixe], 31 MAY 2021 : We highly appreciate this suggestion and accept this new update policy with ILIAS 8. Updating to ILIAS 8 requires an ILIAS 7.x installation. Updating from ILIAS 6 or before will throw an error in the setup. This information needs to be added to the Release 8 page (and later to the release pages in the related LM for roadmap and releases.

10 Implementation

The feature is implemented as described, additionally the setup now prohibits downgrades. See PR 4489 for implementatoin details.

Test Cases

Test cases completed at 2022-05-06 by Amstutz, Timon [amstutz]

• 49906 : Skip Major ILIAS Version

Approval

Approved at 2022-05-06 by Klees, Richard [rklees].