| 27 Oct 2024 |
|  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 |
| 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 |
