Added dynamic entity tracking documentation (#641)

* Change ordering

* Added dynamic entity tracking documentation

source/_components/sensor.google_travel_time.markdown

@@ -40,3 +40,38 @@ Configuration variables:
 - **options** (*Optional*): A dictionary containing parameters to add to all requests to the Distance Matrix API. A full listing of available options can be found [here](https://developers.google.com/maps/documentation/distance-matrix/intro#RequestParameters).
   - **departure_time** (*Optional*): Can be `now`, a Unix timestamp, or a 24 hour time string like `08:00:00`. If you provide a time string, it will be combined with the current date to get travel time for that moment.
   - **arrival_time** (*Optional*): See notes above for `departure_time`. `arrival_time` can not be `now`, only a Unix timestamp or time string. You can not provide both `departure_time` and `arrival_time`. If you do provide both, `arrival_time` will be removed from the request.
+
+
+
+###Dynamic Configuration
+Tracking can be setup to track entities of type device_tracker, zone, and sensor. If an entity is placed in the origin or destination then every 5 minutes when the component updates it will use the latest location of that entity.
+
+```yaml
+# Example entry for configuration.yaml
+sensor:
+  # Tracking entity to entity
+  - platform: google_travel_time
+    name: Phone To Home
+    api_key: XXXX_XXXXX_XXXXX
+    origin: device_tracker.mobile_phone
+    destination: zone.home
+
+  # Tracking entity to zone friendly name
+  - platform: google_travel_time
+    name: Home To Eddie's House
+    api_key: XXXX_XXXXX_XXXXX
+    origin: zone.home
+    destination: Eddies House    # Friendly name of a zone
+```
+
+####Entity Tracking
+- **device_tracker**
+  - If state is a zone then the zone location will be used
+  - If state is not a zone it will look for the longitude and latitude attributes
+- **zone**
+  - Uses the longitude and latitude attributes
+  - Can also be referenced by just the zone's friendly name found in the attributes.
+- **sensor**
+  - If state is a zone or zone friendly name then will use the zone location
+  - All other states will be passed directly into the google API
+    - This includes all valid locations listed in the *Configuration Variables*

source/developers/releasing.markdown

@@ -22,9 +22,10 @@ This page describes the steps for publishing a new Home Assistant release.
 
 1. Create a blog post and base it on the PR text. Add images, additional text, links, etc. if it adds value. Tag each platform/component in message to documentation.
 2. Create missing documentation as stumbs.
-3. Update the link on the frontpage (`source/index.html`) to link to the new release blog post and version number.
-4. Merge blog post and updated frontpage to `master` (`git merge next`).
-5. Change to `next` and merge with `master` (`git checkout next && git merge master`) to keep in sync.
+3. Create a pull request from `next` to `master` with the upcoming release number as title.
+4. Merge `master` into `next` (`git checkout next && git merge master`) to make the PR mergable.
+5. Update the link on the frontpage (`source/index.html`) to link to the new release blog post and version number.
+6. Merge blog post and updated frontpage to `master` (`git merge next`).
 
 ### {% linkable_title Python Package Index %}