| 27 Oct 2024 |
 emily | (during the freeze) | 21:03:24 |
 linj | In reply to @rosscomputerguy:matrix.org
Well, what sort of breaking changes are there? only about the package itself, not related to nix, such as changing the format of its config file | 21:03:31 |
| emily | (whereas there can be no isseus with a deleted package) | 21:03:34 |
| linj | In reply to @emilazy:matrix.org
I don't think so, modulo security concerns, because that could cause issues with that package. what kind of issues do you mean | 21:05:27 |
| emily | maybe you did the update wrong and the package doesn't work properly, maybe the update has some dealbreaking bug that makes it unusable | 21:06:11 |
| emily | I mean, unlikely, for most leaf packages, but it's about derisking and focusing on fixing what we already have. | 21:06:27 |
| emily | removing problematic packages is itself a kind of derisking for the upcoming release. | 21:06:38 |
 Tristan Ross | In reply to @me:linj.tech
only about the package itself, not related to nix, such as changing the format of its config file Imo, changing formats of the config file is kinda breaking. | 21:06:48 |
| Tristan Ross | Ig it's kinda hard to say, we probably should have an exact policy on this stuff | 21:07:38 |
| emily | you should take my opinion with a grain of salt, because I haven't really gotten involved with release process stuff before, but I think the spirit of the freeze is "we now have basically what the next release should be; that release is not going to get breaking changes (within the existing exceptions like security); once the freeze begins, we should focus our efforts on refining and fixing what we have to make the release-as-it-is the best it can be on release, rather than making the kind of change that will be forbidden during the cycle to make 'a better release'" | 21:09:27 |
| emily | * you should take my opinion with a grain of salt, because I haven't really gotten involved with release process stuff before, but I think the spirit of the freeze is "we now have basically what the next release should be; that release is not going to get breaking changes (within the existing exceptions like security); once the freeze begins, we should focus our efforts on refining and fixing what we have to make the release-as-it-is the best it can be on release, derisking the release process rather than making the kind of change that will be forbidden during the cycle to make 'a better release'" | 21:09:45 |
| emily | and while removals wouldn't be allowed during a stable release's lifetime normally, I think it's easy to see how removing stuff that we anticipate to be problematic fits in the spirit of derisking and refining the upcoming release, whereas updating a package to an incompatible version does not | 21:10:11 |
| emily | (unless it has some other major benefit like letting us get rid of some dodgy problematic library or something: in which case that's what freeze exemptions are for) | 21:10:31 |
