Prepare for release

[ci skip]

README.md

@@ -7,6 +7,7 @@ A powerful set of immutable classes to work with dates and times.
 
 [![Build Status](https://secure.travis-ci.org/brick/date-time.svg?branch=master)](http://travis-ci.org/brick/date-time)
 [![Coverage Status](https://coveralls.io/repos/brick/date-time/badge.svg?branch=master)](https://coveralls.io/r/brick/date-time)
+[![Latest Stable Version](https://poser.pugx.org/brick/date-time/v/stable)](https://packagist.org/packages/brick/date-time)
 [![License](https://img.shields.io/badge/license-MIT-blue.svg)](http://opensource.org/licenses/MIT)
 
 Introduction
@@ -30,7 +31,7 @@ Just define the following requirement in your `composer.json` file:
 ```json
 {
     "require": {
-        "brick/date-time": "dev-master"
+        "brick/date-time": "0.1.*"
     }
 }
 ```
@@ -49,6 +50,21 @@ HHVM support is in the works, we are waiting for the HHVM team to fix these bugs
 - ~~#3651 [Incompatible handling of date-times during DST transitions](https://github.com/facebook/hhvm/issues/3651)~~
 - #6954 [Typed variadics not supported in PHP code](https://github.com/facebook/hhvm/issues/6954)
 
+
+Project status & release process
+--------------------------------
+
+While this library is still under development, it is well tested and should be stable enough to use in production environments.
+
+The current releases are numbered `0.x.y`. When a non-breaking change is introduced (adding new methods, optimizing existing code, etc.), `y` is incremented.
+
+**When a breaking change is introduced, a new `0.x` version cycle is always started.**
+
+It is therefore safe to lock your project to a given release cycle, such as `0.1.*`.
+
+If you need to upgrade to a newer release cycle, check the [release history](https://github.com/brick/date-time/releases) for a list of changes introduced by each further `0.x.0` version.
+
+
 Overview
 --------