| 26 Oct 2024 |
 leona | not any in newer versions that aren't fixed in 5.1 tho yet | 18:41:07 |
 emily | I think it's sensible to not ship EOL stuff for the new release. the change of default is a little painful: I would be tempted to throw on old stateVersions explaining the situation rather than potentially silently breaking things. | 18:41:46 |
| emily | that's how I handled it in https://github.com/NixOS/nixpkgs/pull/345625 | 18:42:03 |
| leona | same | 18:42:07 |
| emily | (to be clear though, I have no authority over the release process, just my personal take.) | 18:42:41 |
| emily | (IMO "removing a dead package that we anticipate will cause problems over the course of the release cycle" is one of the more sensible late breaking changes) | 18:43:14 |
 Tristan Ross | In reply to @emilazy:matrix.org
I think it's sensible to not ship EOL stuff for the new release. the change of default is a little painful: I would be tempted to throw on old stateVersions explaining the situation rather than potentially silently breaking things. Agreed | 18:43:59 |
| Tristan Ross | In reply to @emilazy:matrix.org
(IMO "removing a dead package that we anticipate will cause problems over the course of the release cycle" is one of the more sensible late breaking changes) Yeah, it's good to get those in | 18:45:15 |
| Tristan Ross | The freeze is mainly to prevent any packages from breaking that could hurt the release but a security issue is imo more harmful | 18:45:49 |
| 27 Oct 2024 |
|  peterwang joined the room. | 04:32:09 |
|  Scrumplex joined the room. | 19:27:49 |
| Scrumplex | Hi there, short question: Is renaming a package a breaking change assuming an alias is added? | 19:28:30 |
 Vladimír Čunát | Hmm. If your configuration disabled aliases (that's those in aliases.nix), it would be breaking, right? | 19:30:08 |
| Vladimír Čunát | Though easy to fix. | 19:30:36 |
| Scrumplex | But I feel like disabling aliases is like subscribing to breakage | 19:30:51 |
| Scrumplex | In my case I am just worried about causing breakage within Nixpkgs. I was pinged in two separate PRs that involve renaming a package and I wasn't sure if I can merge them during the breaking change freeze | 19:31:46 |
| Vladimír Čunát | My gut feeling is that it's still fine at this point. Maybe until the release. | 19:31:53 |
| Scrumplex | * In my case I am just worried about causing breakage within Nixpkgs. I was pinged in two independent PRs that involve renaming a package and I wasn't sure if I can merge them during the breaking change freeze | 19:31:58 |
| Tristan Ross | The only main case I see this breaking is Ofborg | 19:32:43 |
| emily | aliases shouldn't be used in tree. ofborg breaking if they are is intentional | 19:33:01 |
| Tristan Ross | Hence why I mentioned that lol | 19:33:17 |
| Tristan Ross | But from a user perspective, it wouldn't be breaking because they'd have aliases on | 19:33:36 |
| Scrumplex | So it definitely seems like we don't have a proper policy here so I will just create a PR to try to document a policy. As a new committer I am a little scared to merge something and cause breakage on master, now that I accidentally did so yesterday 👀
I think it would be really valuable to document processes and policies like these for (new) committers.
But this is obviously off topic for this channel ^^ | 19:36:18 |
 Alyssa Ross | We've never prevented removing packages at any time before a release either, fwi.w | 19:36:45 |
| Alyssa Ross | "Breaking change" is not intended to mean "don't change anything" | 19:37:11 |
| Tristan Ross | Yeah | 19:38:36 |
| Vladimír Čunát | In reply to @emilazy:matrix.org
aliases shouldn't be used in tree. ofborg breaking if they are is intentional Sure, you'd need to fix all references in the PR that does the renaming. | 19:38:47 |
| Vladimír Čunát | (and it could be disruptive to other in-progress PRs that reference that name) | 19:39:04 |
| emily | In reply to @scrumplex:duckhub.io
So it definitely seems like we don't have a proper policy here so I will just create a PR to try to document a policy. As a new committer I am a little scared to merge something and cause breakage on master, now that I accidentally did so yesterday 👀
I think it would be really valuable to document processes and policies like these for (new) committers.
But this is obviously off topic for this channel ^^ I think the intent of the breaking change policy is "please don't do anything that could cause issues for ZHF or the release process". | 19:39:20 |
| emily | it's hard to imagine renaming a package, removing a leaf package, etc. doing any of that | 19:39:36 |
