YTEP-0008: Release Schedule¶
Abstract¶
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.
Status¶
Proposed
Project Management Links¶
The Mercurial time based release plan, which has partially inspired this discussion, is available here: http://mercurial.selenic.com/wiki/TimeBasedReleasePlan .
Detailed Description¶
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 |
---|---|---|
1.0.1 | 2008-10-25 | N/A |
1.5 | 2009-11-04 | 375 |
1.6 | 2010-01-22 | 79 |
1.6.1 | 2010-02-11 | N/A |
1.7 | 2010-06-27 | 156 |
2.0 | 2011-01-17 | 204 |
2.0.1 | 2011-01-20 | N/A |
2.1 | 2011-04-06 | 79 |
2.2 | 2011-09-02 | 149 |
2.3 | 2011-12-15 | 104 |
2.4 | 2012-08-02 | 231 |
2.5 | 2013-03-01 | 211 |
2.5.1 | 2013-03-31 | 30 |
2.5.2 | 2013-05-01 | 30 |
2.5.3 | 2013-06-03 | 33 |
2.5.4 | 2013-07-02 | 29 |
2.5.5 | 2013-08-23 | 52 |
2.6 | 2013-11-23 | 92 |
2.6.1 | 2013-12-03 | 10 |
2.6.2 | 2014-02-28 | 87 |
2.6.3 | 2014-07-23 | 145 |
3.0 | 2014-08-04 | N/A |
3.0.1 | 2014-09-01 | 28 |
3.0.2 | 2014-10-03 | 60 |
3.0.3 | 2014-11-03 | 89 |
3.1 | 2015-01-14 | N/A |
3.2 | 2015-07-24 | N/A |
3.2.1 | 2015-09-09 | 47 |
3.2.2 | 2015-11-13 | 65 |
3.2.3 | 2016-02-04 | 83 |
3.3.0 | N/A | |
3.3.1 | 2016-07-24 | 171 |
3.3.2 | 2016-10-26 | 94 |
3.3.3 | 2016-12-12 | 47 |
3.3.4 | 2017-02-13 | 63 |
3.3.5 | 2017-03-08 | 23 |
3.4 | 2017-08-11 | 156 |
3.4.1 | 2018-02-16 | 189 |
3.5 | 2018-10-16 | 242 |
3.5.1 | 2019-02-26 | 133 |
3.6 | 2020-04-11 | 410 |
3.6.1 | 2020-11-13 | 216 |
4.0 | 2021-07-06 | 235 |
4.0.1 | 2021-07-21 | 15 |
4.0.2 | 2022-02-01 | 195 |
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 (stable
)- 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-users
for minor releases and more broadly for major releases)- For “bugfix”-level releases, changes should be backported to a dedicated branch.
Release Managers¶
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
mailing lists.
Version | Release Manager |
---|---|
2.5 | John ZuHone |
2.5.1 | Matthew Turk |
2.5.2 | Matthew Turk |
2.5.3 | Matthew Turk |
2.6 | Kacper Kowalik |
2.6.1 | Matthew Turk |
2.6.2 | Matthew Turk |
2.6.3 | Matthew Turk |
3.0 | Matthew Turk |
3.1 | John Zuhone |
3.2 | Britton Smith |
3.2.1 | Nathan Goldbaum |
3.2.2 | Nathan Goldbaum |
3.2.3 | Nathan Goldbaum |
3.3.0 | Nathan Goldbaum |
3.3.1 | Nathan Goldbaum |
3.3.2 | Nathan Goldbaum |
3.3.3 | Nathan Goldbaum |
3.3.4 | Nathan Goldbaum |
3.3.5 | Nathan Goldbaum |
3.4.0 | Nathan Goldbaum |
3.4.1 | Nathan Goldbaum |
3.5.0 | Nathan Goldbaum |
3.5.1 | Nathan Goldbaum |
3.6.0 | Madicken Munk |
3.6.1 | Madicken Munk |
4.0.0 | Madicken Munk |
4.0.1 | Madicken Munk |
4.0.2 | Matthew Turk |
Backwards Compatibility¶
This should have no backwards-incompatible changes.
Alternatives¶
One alternative would be to forego release numbers and move to completely continuous integration. Another would be to continue on our current path.