YTEP-0008: Release Schedule


Created: February 21, 2013 Author: Matthew Turk

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.



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

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 ( )
  • An announcement email (to yt-users for minor releases and more broadly for major releases)
  • For “bugfix”-level releases, changes should be backported to the stable branch using the script.

Long Term Support Branch

As development on underlying infrastructure of yt continues apace, we must provide long-term support for the existing infrastructure. As such, we will continue to provide (time, effort and need permitting) the existing 2.X branches with critical bugfixes.

Here is an outline of the release dates for the remainder of 2014. This YTEP will be updated as time goes on with additional release dates for long-term stability, but currently it is anticipated that this release schedule will relax over time once the next-generation branch (described below) becomes viable.

This branch will be known as yt-2.x.

Version Release Date
2.6.4 2014-11-01

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

Backwards Compatibility

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.