.. _release:

=======
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.
