Release

Having a release system has many benefits. First and foremost, it makes trying out Theano easy. You can install a stable version of Theano, without having to worry about the current state of the repository. While we usually try NOT to break the trunk, mistakes can happen. This also greatly simplifies the installation process: mercurial is no longer required and certain python dependencies can be handled automatically (numpy for now, maybe pycuda, cython later).

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

1. We will perform a monthly release of Theano. These will be “lightweight” releases and will include everything that was done in the last month. All outstanding feature requests are pushed back to the following month, so as not to delay the current release.

2. Asynchronous releases will only be made when a bug generating incorrect output is discovered and fixed.

3. Each release must satisfy the following criteria. Non-compliance will result 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.

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

   1. We update Z by 1 for each lightweight release.
   2. We update Y for bug fixes, interface changes and/or significant features we wish to publicize.
   3. The Theano v1.0.0 release will be made when the interface is deemed stable enough and covers most of numpy’s interface.

5. The trunk will be tagged on each release.

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

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

Optional:

8. A 1-week scrum might take place before a release, in order to fix bugs which 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.