René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Add support for future-version workflows","articleBody":"In python/cpython#93965, I'm realizing that it would be nice when deprecating some functionality to simultaneously submit the changes to remove the deprecated behavior. That is, it would be nice to be able to author an issue and/or PR that targets Python N+.1 or N+.2 (where Python N is what's on `main`).\r\n\r\nI think such a workflow could be readily achieved by:\r\n\r\n- Add tags for future versions (e.g. 3.13, 3.14) to Github.\r\n- Add a tag for deferred work (maybe call it \"deferred\").\r\n- Advise developers to close deferred items until they're valid.\r\n- When main is updated for a new version, re-open deferred tickets for the new version.\r\n\r\nOther features could be added to streamline the process.\r\n\r\n- Automatically create new tags two versions into the future.\r\n- Disallow merging of \"deferred\" PRs.\r\n- Automatically close deferred items that aren't yet valid.\r\n- Automatically re-open deferred tickets when new branches are created (i.e. creation of 3.11 branch would re-open 3.12 deferred items).\r\n\r\nThis process would enable contributors to scope out a full lifecycle of a deprecation in a single bug with a couple of stacked PRs, one that is merged immediately and another that is deferred until the codebase is ready. This approach has the advantage of implementing the changes near to each other, avoiding loss of context in the interim, and offering a review of both changes together.\r\n\r\nExcept for initial setup, this process would require a tiny bit of extra work when cutting each new minor release.","author":{"url":"https://github.com/jaraco","@type":"Person","name":"jaraco"},"datePublished":"2022-07-02T21:29:05.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/468/core-workflow/issues/468"}