YTEP-0008: Release Schedule¶
Created: February 21, 2013 Author: Matthew Turk Updated: November 3, 2021 Author: Clément Robert
The yt release schedule is somewhat dysfunctional in several ways. Release dates can be difficult to stick to, and merges to stable occur only after long periods. This results in bug fixes not propagating and increases the pressure on developers for a given “release,” as each release is seen as monumental rather than incremental. This YTEP describes a new mechanism for increasing the cadence of point releases as well as merging from the development branch into the stable branch.
The yt release schedule is irregular. Here’s a table of the releases over time, along with the number of days since the most recent major (i.e., non-point) release. Depending on when this document was last updated, this may include both planned and historical releases.
|Version||Release Date||Days Since Last|
In principle, a long release schedule is not a problem. However, what this results in is a reluctance to merge to the stable branch. This has two major side effects: it leads to many people working off of the development branch and it leads to a long time between bug fixes for individuals working off of the stable branch. The development branch, despite its name, is quite stable – however, this also means that when instabilities (or API changes) are introduced in the development branch, it can be much more disruptive.
What Constitutes a Release¶
The majority of development in the primary yt repository is stable. Seldom are backwards-incompatible changes introduced, nor functionality broken. This is helped by continuous integration and detailed code review. As such, for the most part, yt is in a constant state of “release.”
For the purposes of this document, a “release” constitutes five things:
- A new build of the documentation with API and cookbook is placed in a long-term container.
- The development branch (
yt) is merged to the stable branch (
- A new tag in the version control history
- An upload of the source code to PyPI ( https://pypi.org/ )
- An new entry on conda-forge ( https://anaconda.org/conda-forge/yt )
- An announcement email (to
yt-usersfor minor releases and more broadly for major releases)
- For “bugfix”-level releases, changes should be backported to a dedicated branch.
The release manager for minor releases will be Matthew Turk, as they will only
be announced to
yt-users. For major releases, a new release manager will
be selected by consensus in the
yt-dev community. Merging, tagging and
uploading will be handled by Matthew Turk, but the release manager will act as
“whip” to ensure the necessary documentation building is done. Additionally,
this release manager will write the release notes and send the email to various
This should have no backwards-incompatible changes.
One alternative would be to forego release numbers and move to completely continuous integration. Another would be to continue on our current path.