GNOME Shell updates & Yaru

Desktop Theme Refresh
1

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) :slight_smile:

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).

2

I think that making a branch for 18.04 is the cleanest solution. We’re not redoing the work and build system is not tweaked and there is no “what-is-this-18.04-folder-here?” :smiley:

2 Likes
3

A dedicated branch for 18.04 could be a good idea because for 18.04 the gtk and the shell shouldn’t change much more. And then the master would be used for the newest changes in 18.10 then 19.04 and so on.
The snap would be then only made out of the 18.04 branch.
And we would need to make use of dedicated tags on GitHub for the branch(es). Like “this affects 18.04 gtk and/or shell”. :slight_smile:

Edit: this would mean that our designers should switch to meson for testing branches? Which would not be that bad anymore since the frequency of changes became lower in the past weeks and should stay this low.

1 Like
4

I think subdirectories would make it a tiny bit easier for the community to maintain the 18.04 version and keep it up-to-date with the 18.10 version. Many people trip over git branches…

However, branches might make it easier for a skilled person to backport 18.10 changes to 18.04…

My preference goes out to branches. I also think that will be the most future-proof version; we can then use the same approach for 19.04.

2 Likes