I’m modifying the OS as a minimal core without introducing too many customization codes. I’m still looking for a friendly way to upgrade OS “version bundle”. I’m curious, why would Debian/Ubuntu OS release strategy is in a way like point release instead of rolling release like, for example Linux Kernel?
Usually, performing the upgrades using dist-upgrade and equivalent instructions are less stable than fresh install. I want to roll this OS update something similar to MacOS, like Sierra to Mojave: one click and everything done automatically. I can still workaround with an intense remote BASH scripts to achieve the same effect but it’s scary with no guarantees of expected outcome.
I’m specifically looking for past “painful” experience between those release strategies so I can proceed carefully in my exploration and meanwhile not to repeat the same mistake from the past. Yes, I’ll open source the findings once it’s working, as a return to the community.
The idea is to find out whether a rolling release OS core is possible so that we can worry less on “OS” re-installation.
I have my answer now after some thought experiments.
If we implement rolling release strategy, we will end up like Windows 10 case.
Pros:
The update can be unified and the OS structure is rigid and simplified
More update control at scale.
No massive “reformat and reinstall”. Highly suitable for long lifetime control system that can receive on-the-fly updates.
Cons:
Can break certain user experiences patterns. Need to be very cautious about user groups.
Hard to manage update uniformly since not all users updates together and on the spot. Some delay updates intentionally in exchange for operational stability.
No freedom of development (you need to comply to structural standards in order not to break the update paradigm)
If we implement point release strategy, we will end up like Android case. Pros:
Freedom to develop your own system based on the generic copy (e.g. Debian stable releases).
Ensures clean usage and stability offered per point release due to clean reinstall.
Roll updates faster and in a stable manner depending on release schedules.
Cons:
Requires “reformat and reinstall” for every major release.
Less control over massive uniform updates.
Can create a massive lots of variant due to the freedom offered to develop the system. Example: vendor specific Android devices.
Debian/Ubuntu Case
Their primary focus is to build an universal OS core that is suitable for wide-range of deployments, like real-time, general purpose, IoT, etc. Opting for point release strategy with lifespan specific supports (like 5 years / 10 years) makes more sense than rolling strategy.
For this question, it’s better to perform an external “program” or an mini operating system to “reinstall” the entire operating system per major point release.
I might be late but this is a good case study for rolling release strategy: Go Dependency Management
Go programming language initially opted for single caching - rolling release strategy for each of the packages using GOPATH. This is feasible for small scale projects with controllable amount of package volumes.
As the communities and packages grow outside of control, the dependency became problematic due to few things:
Every package owners performs his/her rolling updates, thus, breaking the packages depending on them.
Package owners can go AWOL or delete the repository, creating a security vulnerability (stability, not safety) for all the dependent packages.
Updates rolls into the dependent packages without version control. This welcomes another security vulnerability (like rogue codes) enters the dependent package.
As a resolution to this, Go development team implemented vendor directory in Go 1.5, thus, the start of shifting towards point release strategy. Then, due to the rolling strategy file-system complications, they introduced Go Module in Go 1.11 and totally gave up the initial rolling release strategy and opt-ed for point-release strategy.
Relating back Debian / Ubuntu Operating System, this is the exact problem OS maintainers want to avoid. An Operating System has various packages not limited to a single language, single pattern of package management. Hence, it’s better off go with point release strategy.
. I will play with it next week and likely going to write a short research paper about the findings.