Release Management
==================

After pylint 2.0, which is scheduled to be released somewhere around in
July, we are planning to do releases more often. The intentional plan is
to have a minor release for each two or three weeks, having also the next
major bump planned in advance.

In order for these short minor releases to be manageable, the plan is to
have at most ten issues assigned per minor release. We can try, though,
to assign few than ten issues per release, so we could schedule a fix
really quickly, if the need arises, thus giving ourselves time for the
unplanned.

Although, to advance the capabilities of the inference engine
and of Pylint in general, we cannot focus ourselves completely on working
only for minor releases and as such, the release schedule will have gaps
for working for the next major release of astroid, indifferent on the
corresponding version.



Release Process
===============


When starting developing a new release, a couple of things needs
to be tackled, in order to simplify the late management:

Pre-developing
--------------


1. create a new section in the ChangeLog, with the name of the
   release and the estimated date when it is going to be published.
   If no date can be known at that time, we should use ``Undefined``.

2. create a new ``What's new in Pylint X.Y`` document. Take a look
   at the examples from doc/whatsnew.

Pre-release
----------- 

1. Preparation
   1. Check if the dependencies of the package are correct
   2. Update the version number in __pkginfo__
   3. Put the version number and the release date into the changelog
   4. Put the release date into the ``What's new`` section.
   5. Submit your changes.

2. Make sure the tests are passing on Travis:
   https://travis-ci.org/PyCQA/pylint/

3. Add a new tag 'pylint-$VERSION'

5. Publish all remaining changes to the GitHub repository:
   https://github.com/PyCQA/pylint


Release by running:
   
   $ python setup.py register sdist --formats=gztar bdist_wheel upload

   to release a new version to PyPI.