Pycord Release Schedule (DRAFT) #3087
Pycord Development Admin
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
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.
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 paillat@pycord.dev>
Purpose & Prior Precedent
This document aims at describing the release schedule of Pycord, and its versioning.
Prior to this proposal, the Pycord release schedule was non-standard, and therefore highly dependent
on maintainer feedback and emotion towards a release.
While this approach has been deemed flexible, it has also made it complicated for users to plan their projects around Pycord's updates, and has
ultimately led to significantly undesirable gaps between minor releases (e.g. 1y+ between v2.6.1 and v2.7.0, and
between v2.4.1 and v2.5.0).
Release Guarantees
Note
For an up to date list of Pycord's release guarantees, please
visit 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
This document dictates that Pycord will have the following releases every year:
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 longer 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 there are no substantial changes (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; otherwise it is ignored.
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.
Release Cycle Start Date
This release cycle officially begins in Q1 2026 (February - May), with quadrimesters aligned as follows:
The current cycle (Q3 2025: November 2025 - February 2026) is already following the Minor Quadrimester Plan:
Starting February 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