| 10 Jun 2025 |
 emily | and if we're dropping it for a release we should surely drop it right after branch-off for that release, to not waste half a year building binaries we won't ship | 13:17:57 |
| emily | (Darwin users do get defaulted to nixpkgs-unstable by the installer, so it would be a little weird for half a year, but it'd at least be a single-command fix for the final ~seven months of support.) | 13:19:06 |
| emily | dropping it for 25.11 would be pretty abrupt (and also I'm still on x86_64-darwin so I imagine the expected value would be negative until I buy a new Mac soon given the difficulty it would pose for me helping out during staging cycles and so on :P) | 13:20:35 |
| emily | we could drop for the 26.05 release, but aligning it with the *.11 releases that match new macOS versions makes sense to me in terms of user expectations. | 13:21:09 |
| emily | the only thing that's easy to say for definite is making an exception to the version support policy for 28.11 when it's out of support would be silly. but I don't expect appetite for holding on for those whole three years given how marginal the platform is going to get after this announcement. | 13:22:24 |
| emily | oh, the other factor is that Apple might drop Intel support from the SDK as early as macOS 27, and we've toyed with the idea of always using the latest SDK to build packages. so if we did that then it could be that maintaining support in 26.11 wouldn't be viable. | 13:23:51 |
 Arian | How do we usually test fastly changes? | 18:21:37 |
 hexa (signing key rotation when) | last time we created a temporary hostname against which we test the changes iirc | 18:25:09 |
| Arian | Hmm there is also this: https://www.fastly.com/documentation/guides/getting-started/services/working-with-staging/ | 18:31:16 |
