Release

Having a release system has many benefits. First and foremost, it makes tryingout Theano easy. You can install a stable version of Theano, without having toworry about the current state of the repository. While we usually try NOT tobreak the trunk, mistakes can happen. This also greatly simplifies theinstallation process: mercurial is no longer required and certain pythondependencies can be handled automatically (numpy for now, maybe pycuda, cythonlater).

The Theano release plan is detailed below. Comments and/or suggestions arewelcome on the mailing list.

  • We aim to update Theano several times a year. These releases will be madeas new features are implemented.

  • Urgent releases will only be made when a bug generating incorrectoutput is discovered and fixed.

  • Each release must satisfy the following criteria. Non-compliance willresult in us delaying or skipping the release in question.

  1. No regression errors.

  2. No known, silent errors.

  3. No errors giving incorrect results.

  4. No test errors/failures, except for known errors.

    1. Known errors should not be used to encode “feature wish lists”, as is currently the case.
    2. Incorrect results should raise errors and not known errors (this has always been the case)
    3. All known errors should have a ticket and a reference to that ticket in the error message.

  5. All commits should have been reviewed, to ensure none of the above problems are introduced.

  • The release numbers will follow the X.Y.Z scheme:

    • We update Z for small urgent bugs or support for new versions of dependencies.
    • We update Y for interface changes and/or significant featureswe wish to publicize.
    • The Theano v1.0.0 release will be made when the interface is deemedstable enough and covers most of numpy’s interface.

  • The trunk will be tagged on each release.

  • Each release will be uploaded to pypi.python.org, mloss.org and freshmeat.net

  • Release emails will be sent to theano-users, theano-announce, numpy-discussion@scipy.org and scipy-user@scipy.org .

Optional:

  • A 1-week scrum might take place before a release, in order to fix bugswhich would otherwise prevent a release.
  1. Occasional deadlines might cause us to skip a release.
  2. Everybody can (and should) participate, even people on the mailing list.
  3. The scrum should encourage people to finish what they have already started (missing documentation, missing test, …). This should help push out new features and keep the documentation up to date.
  4. If possible, aim for the inclusion of one new interesting feature.
  5. Participating in the scrum should benefit all those involved, as you will learn more about our tools and help develop them in the process. A good indication that you should participate is if you have a need for a feature which is not yet implemented.