| 1 Jan 2026 |
|  matthewcroughan changed their display name from matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) to matthewcroughan. | 20:06:47 |
| 2 Jan 2026 |
|  amadaluzia changed their display name from amadaluzia (happy new year!) to amadaluzia. | 04:46:43 |
 Sergei Zimmerman (xokdvium) | Will try doing a 2.32.5 with the new github releng workflow 🤞 | 13:15:34 |
| Sergei Zimmerman (xokdvium) | All good, 2.32.5 uploaded https://github.com/NixOS/nix/actions/runs/20660550112/job/59321964612 | 15:16:37 |
 K900 | @Sergei Zimmerman (xokdvium) do you want to catch the staging-nixos merge | 15:17:32 |
| K900 | You have like an hour until next channel timer | 15:17:38 |
| K900 | To get it into nixpkgs | 15:17:46 |
| Sergei Zimmerman (xokdvium) | Hm, 2.32 doesn't need to go through staging-nixos. I can do 2.31 now if we get https://github.com/NixOS/nix/pull/14909 in and hydra works fast enough to build 2.31-maintenance. | 15:18:45 |
| K900 | Oh OK | 15:18:53 |
| Sergei Zimmerman (xokdvium) | Yeah but realise that 2.31 needs love - we had to figure out release automation first. Was planning on doing that right afterwards | 15:19:40 |
| K900 | OK so there is a reason to do a 2.31 release? | 15:20:12 |
| Sergei Zimmerman (xokdvium) | Let me look, need to make sure that we caught all the fixes in there | 15:21:47 |
| Sergei Zimmerman (xokdvium) | But I don't think 2.31-maintenance will get built for this staging-nixos merge though | 15:22:18 |
| K900 | Doesn't have to make the actual merge | 15:23:50 |
| K900 | Just needs to be before any channels start building | 15:23:57 |
| K900 | Which will be in ~an hour | 15:24:04 |
| K900 | @Sergei Zimmerman (xokdvium) nixos-unstable evaluating | 17:00:32 |
| K900 | So I guess next time | 17:00:37 |
| K900 | Hopefully we don't have a 3 week cycle again | 17:00:47 |
| K900 | Well I think the eval died | 17:57:54 |
| K900 | Oh great | 17:58:12 |
| K900 | I think we have a merge conflict | 17:58:16 |
| 3 Jan 2026 |
 Mic92 | So I was thinking about how to version the nix installer, and I was thinking of having the first major and minor number following the nix version number and have the patch release be counted up as we release a new version within in the Nix release. | 12:54:49 |
| Mic92 | Sergei Zimmerman (xokdvium): thoughts? | 12:55:05 |
| Mic92 | This is how I currently do nix-eval-jobs releases as well. | 12:55:28 |
| Mic92 | This reduces a bit the mental overhead of correlating nix versions with the installer | 12:56:08 |
| Sergei Zimmerman (xokdvium) | In reply to @joerg:thalheim.io
So I was thinking about how to version the nix installer, and I was thinking of having the first major and minor number following the nix version number and have the patch release be counted up as we release a new version within in the Nix release. Makes sense. With can automate the version bumps in nix releng workflow I think? | 12:56:42 |
| Sergei Zimmerman (xokdvium) | So that the manual churn is less of a bother. Open a PR + trigger a release on the other side too? | 12:58:15 |
| Mic92 | we could trigger the update there. It would be good to have a way to release installer fixes without bumping the nix version | 13:00:49 |
| Mic92 | Maybe having workflow parameter? | 13:01:17 |
