Pycord Release Schedule (DRAFT) #3087
Paillat-dev
announced in
Announcements
Replies: 2 comments 1 reply
-
|
Heyy everyone, could you please check this out when you got time and leave some big or small feedback if you have it, so that we can go forward with this ? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I approve of the idea, it seems perfectly feasible and logical. I’d reword some of the sentences, but other than that, all seems good |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
What kind of changes where you thinking about ? |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Warning
This document is a DRAFT and should not be considered official nor definitive.
Pycord Release Schedule
Status: Draft
Authors: <Paillat-dev [email protected]>
Purpose of this document
This document aims at describing the release schedule of Pycord, and its versioning.
Pycord has, until now, never had any formal release schedule. It was mostly vibe-based, with releases happening whenever
the maintainers felt like it.
This approach, while flexible, made it difficult for users to plan their projects around Pycord's updates, and
ultimately led to significant undesirable gaps between multiple releases (e.g. 1y+ between v2.6.1 and v2.7.0, and
between v2.4.1 and v2.5.0).
Pycord follows semantic versioning, with some exceptions and guarantees as described below.
Release Guarantees
Note
For a full and up to date list of Pycord's release guarantees, please
see https://docs.pycord.dev/en/stable/version_guarantees.html.
The library follows the semantic versioning principle which means that the major version is
updated every time there is an incompatible API change. However due to the lack of guarantees on the Discord side when
it comes to breaking changes along with the fairly dynamic nature of Python it can be hard to discern what can be
considered a breaking change and what isn't.
The first thing to keep in mind is that breaking changes only apply to publicly documented functions and classes. If
it's not listed in the documentation here then it is not part of the public API and is thus bound to change. This
includes attributes that start with an underscore or functions without an underscore that are not documented.
Release Schedule
Pycord's release schedule consists of:
candidate no later than two weeks before the minor release.
The content of releases follows semantic versioning. The release schedule follows a quadrimestrial cycle.
At the beginning of each quadrimester, if new features are ready for release, the Minor Quadrimester Plan is
followed. Otherwise, the Patch Quadrimester Plan is followed.
Minor Quadrimester Plan:
A second release candidate may be released no later than two weeks before the minor release if needed.
Patch Quadrimester Plan:
The release schedule is followed as planned. Releases include at minimum dependency updates or minor
fixes.
In the rare case that absolutely nothing is available (no dependency updates, no fixes, no changes), the release is
skipped.
In case of an emergency, such as a security issue, a patch release is made as soon as possible.
It counts as the planned patch release if it occurs during a month where a patch is already scheduled, else it is
ignored release-planning wise.
Feature Freeze
three days before the respective Minor release. A second release candidate may be released no later than two weeks
before the minor release.
Release Tracking
GitHub Milestones
GitHub milestones must be maintained for all upcoming releases in the current quadrimestrial cycle.
Schedule Start Date
This release schedule officially begins with Q1 2026 (March - June), with quadrimesters aligned as follows:
The current cycle (Q3 2025: November 2025 - February 2026) is already following the Minor Quadrimester Plan:
Starting March 2026 (Q1 2026), all quadrimesters follow the standard 4-month cycle as described in this document.
Roles and Responsibilities
Pycord Maintainers
At the start of each quadrimester, maintainers assess together available features and decide on the quadrimestrial
plan within the first week. Once the plan is decided, it is announced and pinned in the
#discussionchannel ofthe
PycordDiscord server.Pycord maintainers are responsible for deciding unanimously on the release schedule and for the release process. In case
of conflicts, the decision may be escalated to the release managers.
Once a release is ready, Maintainers inform the current Release Managers.
Release Managers
The Release Managers consist of Pycord Project Managers and Project Leads. They are responsible for the release
process.
This consists of:
Release Schedule Flowchart
flowchart TD Start(["Start of Quadrimester"]) --> Month0Start["Month 0"] Month0Start --> Assess{"Maintainers assess:<br>Features ready?"} Assess -- Yes --> MinorDecision["Minor Quadrimester"] Assess -- No --> PatchDecision["Patch Quadrimester"] MinorDecision --> Announce["Maintainers:<br>Announce in #discussion<br>Pin message"] PatchDecision --> Announce Announce --> CreateMilestones{"Maintainers:<br>Create milestones"} CreateMilestones -- Minor --> M_Milestones["Milestones:<br>RC, Minor, Patch"] CreateMilestones -- Patch --> P_Milestones["Milestones:<br>2 Patches"] M_Milestones --> M_Month1["Month 1:<br>Feature Freeze<br>Release RC<br>Close milestone"] P_Milestones --> P_Month1["Month 1:<br>Release Patch<br>Close milestone"] M_Month1 --> M_Month2["Month 2:<br>Release Minor<br>Close milestone"] P_Month1 --> P_Month2["Month 2:<br>n/a"] M_Month2 --> Month3["Month 3:<br>Release Patch<br>Close milestone"] P_Month2 --> Month3 Month3 --> End(["End of Quadrimester"]) style Start fill:#e1f5e1,color:#000 style Assess fill:#fff4e1,color:#000 style CreateMilestones fill:#fff4e1,color:#000 style M_Month1 fill:#ffe1e1,color:#000 style End fill:#ffe1e1,color:#000Beta Was this translation helpful? Give feedback.
All reactions