DietPi-Update | Apply new update system that allows automatic branch migration #4103
Conversation
+ DietPi-Update | Remove https://dietpi.com/ update server. Access to the GitHub repository is required anyway to download the dietpi.txt and for various software configs, when being patched or reinstalled, so it's even better to exit in the very first place instead of running into failing connections at a later stage.
MichaIng
requested review from
ravenclaw900,
Fourdee,
fpetru,
Joulinar and
StephanStS
|
Wow, v7. Will this come after or replace 6.35? |
|
To allow a smoother drop of support for old Debian versions (Stretch somewhere this year) and as well old DietPi versions, without having to radically break the update ability, I added this method to natively migrate users to separate branches in case automatically, where we can theoretically provide some kind of LTS support, e.g. applying important/security patches for a while, or in case of Debian Stretch implement prompts/hints about how to dist-upgrade to a supported Debian version and then migrate back to the master/stable branch. This way we don't need to handle complicated and error-prone migration and update-restart cycles and steps in the main branches. This has become quite complicated already and requires a lot of update-path testing to assure that none is broken. Another major aim is to not completely break updates from older versions when incrementing the major/core version. Instead we can now start to drop support for a tail of very old subversions to simplify the patch file step by step until it (the old one) can be removed completely in two years or so. Then, the It was not required, but since it became possible now, I did increment the major version to v7.0, so that v6.35 is a transition version only, required as intermediate step before an update restart migrates to the new system. But aside of that, it's not a large update, so no deeper meaning. A little like Linux 5.0 being to larger update than 4.19 or 5.1 😄. What do you think? |
+ DietPi-Update | After three years, remove the DietPi pre-v6 version file. This means that these DietPi systems won't see a "new image available" message, indicating that a new image needs to be flashed, but the update check will fail instead, which practically the same can be derived from.
|
does it means, DietPi version updates are populated to people running latest Debian Buster atm? And for Stretch we just provide bug-fixing? Just for my understanding 🤣 |
For now nothing changes about version support, only Jessie systems would be migrated. But those will never execute that code, as they are migrated via But yes, once we decide to drop support for Stretch from the main repository code, we can then keep a minimal support on that dedicated branch, backporting only important fixes, depending also on reports/demand or user contributions. |
|
probably as well we could prompt a banner info about Stretch being eol somewhere mid of the year too 🤔 |
Good idea. We did similar for Jessie users two years ago, via MOTD, so there is some buffer to find a spare-time weekend for a dist-upgrade or fresh flash instead of a surprise all of a sudden. |
|
Officially we did not support |
|
Yes, I'd still always recommend a fresh flash instead of a dist-upgrade, but many users ignore(d) that anyway and then it's better to have some documented best practice instructions or even start supporting it officially, which forces us to review/learn more about possible unwanted left-overs. Some software options might require a reinstall and such to remain functional. And indeed it became much less risky than it was a few Debian versions ago. I saw quite some more changelog entries were dist-upgrades were particularly taking into account. |
Status: Review
Commit list/description: