YTEP-3000: Let’s all start using yt 3.0!


Created: October 30, 2013 Author: Matthew Turk

This is a YTEP suggesting we all start using yt 3.0 for development, and where the blockers to adoption are enumerated.



Detailed Description

This YTEP outlines the items necessary to be implemented before yt 3.0 can be released, and before we can attempt to move development and day-to-day usage for developers to the 3.0 codebase.

There are essentially three categories of work items: release blockers, necessary features to migrate usage and development, and feature parity requirements.

Several developers have expressed that a major blocker is concluding work they have begun on yt 2.6 and the 2.x branch; this document is meant to supplement that, rather than replace it.

Release Blockers

These are components that need implementing before yt 3.0 can be released. This is not the same as reaching a “complete” implementation; the important work is to ensure that subsequent API breakages are minimal. We are tracking these on the yt-3.0 Trello Board.

  • Merging unitrefactor; waiting only on documentation and rebranding merge at this time. (YTEP-0011 and YTEP-0017.)
  • De-astroification of yt and renaming of generic objects which has been mostly accomplished in the rebranding bookmark.
  • Removing dict-like access to static output (YTEP-0018), not yet compelted in the rebranding bookmark.
  • Considerable amount of documentation, which is being worked on.

I do not believe there are any other blockers to yt 3.0.

Necessary Features

These are items that are necessary for developers to migrate from using and developing yt 2.6 to yt 3.0.

This is intentionally left mostly empty, as items from “feature parity” will be migrated up.

  • field_cuts (which is a related to cut_region, which has been mostly implemented.)

Feature Parity

These are items that existed in yt 2.6 that do not exist in yt 3.0 yet.

  • A handful of hierarchy attributes have not yet been implemented.
  • A few frontends still need polishing during the port, including Chombo, Pluto, NMSU-ART, and GDF. These are small items but will need assistance from individual frontend maintainers.
  • The sidecar storage has not been ported.
  • Boolean regions have not been implemented. They can likely be implemented in the same manner as cut_region has been.

Backwards Compatibility

This does not add any new backwards incompatible items, it is merely a call to action.


Call a mulligan, start over?