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

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.