I have started to document the update GNOME Shell procedure versus Yaru theme when there are theme updates.
The question is thus about 18.04 users, after the first update with GNOME Shell incompatible changes. If we don’t do anything, we’ll deliver an incompatible master, and consequently, incompatible snap to them.
If we want to keep bionic users updating, it means that we need to double the work. We have three ways of dealing with that:
- cp -a
gnome-shell/src/ gnome-shell/src-18.04/
before any incompatible change is made, tweak the build system to build in the package the first directory and in the snap the second one. However, it means the MP, if you want to support both, will be larger - kind of similar but branching for 18.04 and reporting the changes at a regular pace. The benefit is that there is no build system changes to be done (only one to tell “the snap is only from that branch” and PR are smaller (we mainly target master, and only report via a MP like once a week to 18.04 branch, reverting newer GNOME Shell specific changes.
- Support both in the same sass files, which means, longer sass files (every renamed class, removed properties and class are staying forever), harder to maintain and such.
Ofc, there is as well the option to not support bionic at the first breakage change (just mentioning it for completeness of options)
Tell me what you think @c-lobrano, @frederik-f , @merlijn-sebrechts as I think you will be the most impacted?
EDIT: Note that as of today, there is no backward incompatible changes in 3.29.x Shell tree (only some colors/padding changes + new classes which will be unused by bionic Shell version), so we don’t need to diverge and add uneeded extra work, but better to plan right now on our strategy).