| 27 Oct 2024 |
 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 |
| emily | whereas, e.g. merging a coreutils or ninja update or something that changed semantics could cause late-breaking chaos. | 19:39:50 |
| Scrumplex | Makes sense. I'll try to incorporate this in our documentation | 19:43:37 |
| emily | feel free to tag me for my unsolicited opinions :P | 19:45:04 |
| emily | though I guess that would make them solicited | 19:45:08 |
| Tristan Ross | Unsolicited solicitation | 19:45:36 |
|  @grossmap:in.tum.de joined the room. | 20:25:26 |
 linj | so updating a package to a new version which contains breaking changes is still allowed/never restricted? | 20:36:27 |
| linj | * | 20:37:30 |
| Tristan Ross | Well, what sort of breaking changes are there? | 20:59:38 |
| emily | In reply to @me:linj.tech
so updating a leaf package to a new version which contains breaking changes is still allowed/never restricted? I don't think so, modulo security concerns, because that could cause issues with that package. | 21:03:20 |
| 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 |
