stylix: add release-24.11 branch

[trueNAHO]

Considering that nixos-24.11 is available, we should create our 24.11 release:

git branch release-24.11 master && git push danth release-24.11

Based on recent issues, Stylix seems to be "slightly" broken with the current input versions. Should we first resolve those problems or already release our release-24.11 branch and backport the fixes?

---

Cc: @danth

[DockterTeagle]

I cant get stylix to break on me with something other than nixpkgs with this flake.I think that releasing a branch like this could be very helpful, sorry if I wasnt supposed to comment on this one.

[arunoruto]

How hard is it to backport things to a potential 24.11 release?
nixpkgs is doing the same thing currently with the beta release of 24.11.

[trueNAHO]

How hard is it to backport things to a potential 24.11 release? nixpkgs is doing the same thing currently with the beta release of 24.11.

It's not hard. It's just additional maintenance. IMHO, it might be best to create the stable branch now.

Unfortunately, I don't have permission to create the release-24.11 branch. AFAIK, only @danth can do that.

I noticed that Stylix uses a non-standard naming convention for stable branches: release-<YY>-<MM> instead of nixos-<YY>-<MM>. I am unsure whether we should break the current naming scheme and call the next stable release nixos-24.11 or release-24.11.

[arunoruto]

It's not hard. It's just additional maintenance. IMHO, it might be best to create the stable branch now.

That would be great. From my usage perspective, only Gnome would need some tweaking, since the theming seems a bit broken as described in #618.

I noticed that Stylix uses a non-standard naming convention for stable branches: release-<YY>-<MM> instead of nixos-<YY>-<MM>. I am unsure whether we should break the current naming scheme and call the next stable release nixos-24.11 or release-24.11.

Maybe I am wrong, but maybe it is based on how home-manager does it. They also only have release-ab.xy branches which match the current NixOS version. I heard that the only difference between release- and nixos- branches, is that nixos- is derived from release-. People can commit to release- but the changes need to be accepted manually to nixos-.

[jalil-salame]

#657 fully breaks 24.11 (I wasn't having issues until this morning). It should be fine to pin to d13ffb3 (for me at least)

[trueNAHO]

#657 fully breaks 24.11 (I wasn't having issues until this morning). It should be fine to pin to d13ffb3 (for me at least)

In that case, the release-24.11 branch should be created with:

git branch release-24.11 d13ffb381c83b6139b9d67feff7addf18f8408fe &&
 git push danth release-24.11

[danth]

@trueNAHO I've created the branch, and relaxed the branch protection rules so you should be able to create other release branches in the future :)

[arunoruto]

#657 fully breaks 24.11 (I wasn't having issues until this morning). It should be fine to pin to d13ffb3 (for me at least)

Same here.
Maybe it is too far-fetched, but would it be possible to check if an option is even present before trying to access it? I made a fork and tried it out, and it seems to work for now: arunoruto@baa1e22 (I am running hm 24.11 and have no access to kubecolor, but it works. I have not tested it if kubecolor is available, but it should be picked up.)

It boils down to replacing programs.kubecolor.settings = { with

    programs = lib.optionalAttrs (config.programs ? kubecolor) {
      kubecolor.settings = {

I am aware that it is more troublesome, but it is a potential fix and would eliminate the need for release branches.
A warning could be printed if the stylix module is enabled, but the keyword is not found in programs.

[danth]

Maybe it is too far-fetched, but would it be possible to check if an option is even present before trying to access it?

This has been discussed before in previous issues. Although we could potentially avoid release branches using this, it increases code complexity, and it's likely to be forgotten about and not removed when the option is fully released.

There are also other uses for release branches, for example the GNOME module which targets a particular version of GNOME. We would otherwise have to maintain multiple sets of patches on the master branch for all the currently available versions.