Add a change log

Adds an initial (template) change log, with a description on its usage
in the CONTRIBUTING documentation.

CHANGES.rst

@@ -0,0 +1,56 @@
+Version x.y.z (unreleased)
+==========================
+
+Release date: unknown
+
+New features
+------------
+
+- Editable mode: allows editing a local repository from a live container [#421]
+
+- Change log added [#426]
+
+
+API changes
+-----------
+
+
+Bug fixes
+---------
+
+
+
+Version 0.6
+===========
+
+Released 2018-09-09
+
+
+Version 0.5
+===========
+
+Released 2018-02-07
+
+
+Version 0.4.1
+=============
+
+Released 2018-09-06
+
+
+Version 0.2
+===========
+
+Released 2018-05-25
+
+
+Version 0.1.1
+=============
+
+Released 2017-04-19
+
+
+Version 0.1
+===========
+
+Released 2017-04-14

CONTRIBUTING.md

@@ -6,6 +6,7 @@ This document covers:
 - Setting up for Local Development
 - Running Tests
 - Updating and Freezing BuildPack Dependencies
+- Updating the change log
 - Creating a Release
 
 
@@ -191,7 +192,52 @@ See the subsections below for more detailed instructions.
     repo2docker/buildpacks/conda/environment.py-3.6.frozen.yml
     ```
 
-4. Make a pull request.
+5. Make a pull request; see details below.
+
+6. Once the pull request is approved (but not yet merged), Update the
+   change log (details below) and commit the change log, then update
+   the pull request.
+
+
+### Change log
+
+To add your change to the change log, find the relevant Feature/Bug
+fix/API change section for the next release near the top of the file;
+then add one or two sentences as a new bullet point about your
+changes. Include the pull request or issue number between square
+brackets at the end.
+
+Some details:
+
+- versioning follows the x.y.z, major.minor.bugfix numbering
+
+- bug fixes go into the next bugfix release. If there isn't any, you
+  can create a new section (see point below). Don't worry if you're
+  not sure about that, and think it should go into a next major or
+  minor release: an admin will let you know, or move the change later
+  to the appropriate section
+
+- API changes should preferably go into the next major release, unless
+  they are backward compatible (for example, a deprecated function
+  keyword): then they can go into the next minor release. For release
+  with major release 0, non-backward compatible breaking changes are
+  also fine for the next minor release.
+
+- new features should go into the next minor release.
+
+- if there is no section for the appropriate release, you can add one:
+
+  follow the versioning scheme, by simply increasing the relevant
+  number for one of the major /minor/bugfix numbers, appropriate for
+  your change (see the above bullet points); add the release
+  section. Then add three subsections: new features, api changes, and
+  bug fixes. Leave out the sections that are not appropriate for the
+  newlye added release section.
+
+Release candidate versions in the change log are only temporary, and
+should be superseded by either a next release candidate, or the final
+release for that version (bugfix version 0).
+
 
 ### Make a Pull Request