| 14:45 | <ljharb> | Michael Ficarra: to be clear i'm not, like, refusing to merge it, but if i merge it then we'll have to discuss it in plenary and i'm hopeful to avoid that |
| 14:46 | <ljharb> | i feel like we (tc39) either needs to decide the year is important - and then Annex E is critical, backporting bugfixes to the candidate is critical (which yall three haven't wanted to do much this year or in past years), and then it's fine to link to the snapshots - or, the year's just ecma bureaucracy, and we should only do the bare minimum to satisfy ecma, and we should be linking to the living standard on github everywhere we can |
| 14:47 | <ljharb> | but for the better part of a decade many delegates have been pushing the narrative that it's a living standard, that what's on github is what matters, etc, and linking to ecma's website undermines that |
| 14:49 | <ljharb> | (it'd be a fair point that these links predate the PR and the PR is just updating them, which is fine, but i hadn't realized we were linking to ecma's website in this context still) |
| 14:50 | <Michael Ficarra> | ljharb: we considered 2 options: link to the editors' draft and be burdened with updating the reference to the corresponding yearly release when we cut our own yearly release, or just say "the corresponding yearly release" and for the editors' draft, that kind of implies that the corresponding version is also the editors' draft (since you're not currently looking at a yearly release) |
| 14:50 | <Michael Ficarra> | we went with the latter because we didn't want that additional maintenance burden |
| 14:51 | <ljharb> | why would we have to update it |
| 14:52 | <ljharb> | it's good for us if the snapshot on ecma's website points people to the real spec. they can update it if they want to. |
| 15:11 | <Michael Ficarra> | when we cut the 2024 edition, it should point to the 2024 edition of 402 |
| 15:11 | <Michael Ficarra> | not to the editors' draft |
| 15:12 | <ljharb> | why? |
| 15:12 | <ljharb> | the 2024 edition of 402 is either the same as the draft, or, it's obsolete already |
| 15:12 | <ljharb> | we don't want anyone looking at the snapshots, ideally. we only produce those for ecma imo. |
| 15:13 | <ljharb> | if we could put a big red warning on the ones on ecma's site pointing people to the latest one, we would |
| 15:13 | <Michael Ficarra> | yes, but someone trying to conform to a yearly release should be conforming to the corresponding yearly release of 402 |
| 15:13 | <Michael Ficarra> | it may not even integrate properly with the editors' draft anymore |
| 15:13 | <ljharb> | nobody should be trying to conform to a yearly release |
| 15:13 | <Michael Ficarra> | but that is the person we are considering at the moment! |
| 15:14 | <ljharb> | but sure, i see the point. i think that's a really easy thing to automate tho, and i'm happy to do it manually once a year compared to having the wrong link the rest of the year |
| 15:14 | <Michael Ficarra> | I am concerned about the fragility of that process |
| 15:15 | <Michael Ficarra> | I'd maybe be okay with it if we had a CI process that ran on the release branches that could check it or somethign |
| 15:15 | <ljharb> | sure, i'm fine with adding that too |
| 15:16 | <ljharb> | but also, the downside of that process being skipped is that someone doing a bad thing - trying to conform to a yearly release - might have to do a bit of extra work to find a yearly release. and in that scenario, ecma can make manual updates to fix the links (they've done so in the past for different href issues) the downside of keeping the ecma links is that people will be implementing an obsolete snapshot that may contain un-backported spec bugs |
| 15:16 | <ljharb> | and i think the latter is far more likely than the former |
| 15:17 | <Michael Ficarra> | on Ecma's page about 262, it links to the editors' draft |
| 15:17 | <Michael Ficarra> | maybe the 402 editors should ask Ecma to update their page to also link to the draft |
| 15:17 | <ljharb> | which is great, we had to advocate for that as i recall |
| 15:17 | <ljharb> | yes, they should |
| 15:17 | <Michael Ficarra> | then that should be sufficient |
| 15:19 | <ljharb> | that would still be unnecessary indirection |
| 15:19 | <ljharb> | but i agree at that point, then this change wouldn't be as harmful as i'm suggesting |
| 15:20 | <ljharb> | i can very easily update the build process to replace the tc39.es links for ecma ones before next march, if that fragility is a concern |
| 15:20 | <Michael Ficarra> | I will talk to bakkot about it again today and let you know what we decide |
| 17:28 | <bakkot> | Linking to the draft version from the annual version is definitely wrong because it is not generally going to be consistent |
| 17:28 | <bakkot> | I am OK with any option which does not have that property |
| 19:10 | <ljharb> | i agree it's wrong, and would prefer it not be wrong, but i also care the least about that particular bad outcome (and i think it's easy to avoid) |
| 19:14 | <Michael Ficarra> | I've opened https://github.com/tc39/ecma402/issues/795 |