GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Add support for future-version workflows · Issue #468 · python/core-workflow

Add support for future-version workflows #468

New issue
Copy link
New issue
Copy link
Closed as not planned
Closed as not planned
Add support for future-version workflows#468
Copy link

Description

@jaraco
jaraco
opened on Jul 2, 2022
Issue body actions

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).

I think such a workflow could be readily achieved by:

  • Add tags for future versions (e.g. 3.13, 3.14) to Github.
  • Add a tag for deferred work (maybe call it "deferred").
  • Advise developers to close deferred items until they're valid.
  • When main is updated for a new version, re-open deferred tickets for the new version.

Other features could be added to streamline the process.

  • Automatically create new tags two versions into the future.
  • Disallow merging of "deferred" PRs.
  • Automatically close deferred items that aren't yet valid.
  • Automatically re-open deferred tickets when new branches are created (i.e. creation of 3.11 branch would re-open 3.12 deferred items).

This 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.

Except for initial setup, this process would require a tiny bit of extra work when cutting each new minor release.

Activity

  1. ezio-melotti commented on Jul 2, 2022

    @ezio-melotti
    ezio-melotti
    on Jul 2, 2022
    Member
    More actions

    I think the approach can be simplified. We already have a DO-NOT-MERGE label that can be applied to PRs that should be used in the future, and we can just leave them open until it's time to merge them. To know when they can be merged, there a few different approaches:

    • use warnings._deprecated(name, "merge GH-12345 to fix this", remove=(3, N+1)) to warn once it's time to remove the function
    • add tests decorated with @skipIf(sys.version_info < (3, N+1), "merge GH-12345 to fix this") that activate once the release version is bumped;
    • enforce the use of the .. deprecated-removed: directive (see Enforce the use of deprecated-removed in docs cpython#92564) in order to track what and when is supposed to be removed;
    • manually go through the list of deprecated features in the whatsnew for each release (https://docs.python.org/3.12/whatsnew/3.12.html#deprecated)

    In addition, we can use checklists in the issue to track all the relevant PRs (see this (unrelated) comment that contains an example of a checklist with issues/PRs/todos)

    Reacted by Jason R. Coombs
  2. AA-Turner commented on Aug 12, 2025

    @AA-Turner
    AA-Turner
    on Aug 12, 2025
    Member
    More actions

    Closing, stale.

  3. AA-Turner
    closed this as not plannedon Aug 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.