| 22 Jun 2023 |
|  @archive:matrix.org set their display name to archive.matrix.org/faq. | 05:26:27 |
| 23 Jun 2023 |
 Robert Hensing (roberth) | We should really really write down migration guidelines | 10:23:47 |
| Robert Hensing (roberth) | "manually" holding off migration disasters like this is a fucking drain https://github.com/NixOS/nixpkgs/pull/238331#pullrequestreview-1494880730 | 10:24:34 |
| Robert Hensing (roberth) | apologies for the rude language | 10:24:41 |
 raitobezarius | I would argue that it would be a good occasion to clarify | 10:27:05 |
| raitobezarius | (1) Nixpkgs Internal Changes "release notes" (how to communicate API breakages, etc.) across our users and more | 10:27:20 |
| raitobezarius | (2) Public API vs private API promises (not necessarily a solution, but maybe have an easy way to declare from the get-go "this is private", "this is public") | 10:27:46 |
| raitobezarius | (I don't think versioning at this step makes any sense) | 10:28:04 |
 Alyssa Ross | I don't see how a public vs. private distinction could make sense for Nixpkgs | 10:28:43 |
| Robert Hensing (roberth) | The release notes are often quite useless with stuff like renames that are already handled by the system. Just look at the log. | 10:29:15 |
| Robert Hensing (roberth) | Public: everything that's documented | 10:29:22 |
| Alyssa Ross | What does "documented" mean in this case? | 10:29:49 |
| Robert Hensing (roberth) | Private: use common sense. Don't import files except the listed ones <list> | 10:29:53 |
 @piegames:matrix.org | In reply to @roberthensing:matrix.org
The release notes are often quite useless with stuff like renames that are already handled by the system. Just look at the log. We could easily add the release notes editors to summarize these instead | 10:29:54 |
| Robert Hensing (roberth) | Documented in the manual | 10:30:01 |
| Alyssa Ross | ah | 10:30:06 |
| Alyssa Ross | I'm not sure we're ever promised that stable and unstable would be API-compatible | 10:32:08 |
| Robert Hensing (roberth) | Well, about time then | 10:32:46 |
| Robert Hensing (roberth) | Or are we going to break people's stuff at a whim | 10:32:56 |
| Alyssa Ross | that's what "unstable" means | 10:33:04 |
| Alyssa Ross | and in fact, we're not breaking anything, we're just adding warnings | 10:33:23 |
| Robert Hensing (roberth) | Unstable means "let's break stable for everyone who cares about unstable"? | 10:33:32 |
| Robert Hensing (roberth) | that can't be right | 10:33:34 |
| Robert Hensing (roberth) | if we want nixpkgs to be a drag on third party maintainers, then that's how you do it | 10:34:08 |
| Alyssa Ross | I'm sympathetic to the idea that we should not add warnings to functions that are the only option on stable, but it's certainly not a widespread existing convention. | 10:34:10 |
| Alyssa Ross | And it has downsides for Nixpkgs maintainability — it turns an atomic change into a six month long project. | 10:34:35 |
| Alyssa Ross | What if we backported the new functions, without a warning? | 10:35:00 |
| Alyssa Ross | And then added the warning on unstable? | 10:35:07 |
| Alyssa Ross | It would be a totally valid backport, because it would be entirely additive. | 10:35:33 |
| Robert Hensing (roberth) | That's still not atomic, so I wouldn't bother with shortening the deprecation window | 10:36:17 |
