RFC notifications bot (Jun 26 2022 at 00:35): RFC notifications bot (Jun 26 2022 at 00:35):cfallin commented on issue #24:
In principle this seems reasonable, but I'll note that this will break a number of links across the Internet -- scattered throughout GitHub comments at least, and e.g. some of my own links in recent blog posts. We should probably have a defined standard for "stable link to an RFC": do we link to the PR itself (and then keep an up-to-date link in the PR's first comment to the final markdown path)? Or something else?
RFC notifications bot (Jun 27 2022 at 13:55):Kylebrown9 commented on issue #24:
My thought was that post-migration, every PR would include an update that puts the PR number in the file name. From then on the RFC name/path shouldn't need to ever change and a link to the PR or the file can be used to identify it permanently.
As for handling existing links to RFC files that would no longer be correct, the only way to avoid breaking them that I can think of is to make the accepted folder essentially an archive keeping all of the files therein but replacing the contents of each with a link to the actual RFC in some new folder where all of the files are numbered. The issue being that this would make the structure of the RFCs repo a awkward/confusing.
Is there any way to estimate the amount of these links that exist in the wild?
RFC notifications bot (Jul 02 2022 at 15:36):EdorianDark commented on issue #24:
Is there any way to estimate the amount of these links that exist in the wild?
An alternative to break old links would be to rename the files and then to add new files with the old name which only include a link to the new place.
RFC notifications bot (Jul 08 2022 at 19:28):EdorianDark edited a comment on issue #24:
Is there any way to estimate the amount of these links that exist in the wild?
An alternative to break old links would be to rename the files and then to add new files with the old name which only include a link to the new place.
Last updated: Oct 23 2024 at 20:03 UTC