readme: update LTS plan based on new release plan and openssl lts

* Update the details based on the adopted release plan
* Modify the v0.12 maintenance expiration date to align
  with OpenSSL v1.0.1 LTS end

README.md

@@ -24,7 +24,7 @@ The Current LTS Plan is:
    approximately one year after the initial LTS release from the converged
    repo. The existing joyent/node v0.12 will continue in LTS for a period
    of 6 months after the initial LTS release from the converged repo,
-   after which it will transition into Maintenance for 12 months.
+   after which it will transition into Maintenance for 9 months**.
 6. There will be no LTS releases cut from the nodejs/io.js stream.
 7. Once a release enters LTS, no new features may be added to that release.
    Changes are limited to bug fixes, security updates, possible npm updates,
@@ -46,6 +46,14 @@ The Current LTS Plan is:
     release, the LTS Working Group will select a handful of candidate names
     and submit those for a collaborator vote.
 
+** LTS for the version of OpenSSL used by v0.12 (v1.0.1) is scheduled
+   to expire on 2016-12-31. While the typical maintenance LTS cycle
+   for a node release is 12 months, the LTS for OpenSSL v1.0.1 would
+   expire 3 months before the LTS for v0.12 would expire. The LTS WG
+   has therefore decided that the best approach is to shorten the
+   maintenance period for v0.12 and align it's end date with that of
+   OpenSSL v1.0.1's end date.
+
 ## Node abstraction layer
 
 It should be stated that the abstraction layer (currently `NAN`) should
@@ -55,43 +63,41 @@ any given point in time, fully support a maximum of 2 LTS releases.
 
 ## Example
 
-The specific details may vary depending on the `next` and `master` release plan
-that is ultimately adopted. However, the release plan will not impact the
-schedule or proceses for managing an LTS release once it has been cut.
-
-For example. Let's suppose that convergence of the source streams is completed.
-For the sake of the example, let's assume that the first converged stream
-release is v4.0.0 (the next major after the then current io.js release).
-
-Let's suppose that the revised release plan currently being discussed in
-https://github.com/nodejs/io.js/issues/1997 is adopted. This would mean
-that there are regular, periodic merges from the `next` branch into `master`
-that trigger a `semver-major` bump (assuming at least two per year, six months
-apart). Let's assume that the current `master` immediately before the `next`
-merge is at v4.4.1. When the `semver-major` bump from `next` occurs, v4.4.1
-becomes the LTS release. If there are several merges from `next` into `master`
-through the year, the LTS release will still only occur once per year, at the
-same time each year.
-
-Let's assume (hypothetically) that this first LTS Release occurs on
+Following the new release plan, at roughly six month intervals, a new stable
+branch is cut off `master`. Each stable branch represents a semver-major
+version. The first new stable branch cut off the converged stream will be
+`v4.0.0`. Assuming there are additional semver-minor and semver-patch bumps
+in that stable branch, the version could increase to some arbitrary number
+(e.g. `v4.4.1`). At around early October 2015, the v4.x stable branch will
+transition into the first LTS release.
+
+Roughly six months later, a new stable branch will be created for `v5.0.0`.
+While this will be a stable branch, it will *not* transition into LTS.
+
+Roughly six months after `v5.0.0` is cut, the `v6.0.0` stable branch will be
+created. Approximately six months later, at around the same date the `v4.x`
+LTS was cut the previous year, `v6.x` will transition in to LTS and the cycle
+repeats.
+
+Let's assume (hypothetically) that the first LTS Release occurs on
 October 1st, 2015.
 
 1. nodejs/node v4.4.1 becomes the current LTS Release
 2. joyent/node v0.10 continues in Maintainance only mode until
    October 1st, 2016
 3. joyent/node v0.12 continues as LTS until April 1st, 2016, after
-   which it moves into Maintenance only mode until April 1st, 2017.
-4. On or around October 1st, 2016, the second LTS Release from the
-   converged is cut.
+   which it moves into Maintenance only mode until ~~April 1st, 2017~~
+   December 31st, 2016.
+4. On or around October 1st, 2016, `v6.x.x` transitions into
+   the second LTS release.
 5. LTS for v4.4.1 continues until April 1st, 2017, after which it
    moves to Maintenance mode until around April 1st, 2017.
-6. On or around October 1st, 2017, the third LTS Release from the
-   converged is cut.
+6. On or around October 1st, 2017, `v8.x.x` transitions into
+   the third LTS release.
 
-Note that one implication of this schedule is that assuming that `next` merges
-into `master` twice per year, the LTS would be cut with a V8 version that is at
-least six months old and that will need to be supported for up to 30 months
-beyond the LTS release.
+Note that one implication of this schedule is that the LTS would include a V8
+version that is at least six months old and that will need to be supported for
+up to 30 months beyond the LTS release.
 
 <table>
 <tr>
@@ -110,7 +116,7 @@ beyond the LTS release.
   <td>v0.12</td>
   <td>(current)</td>
   <td>2016-04-01</td>
-  <td>2017-04-01</td>
+  <td>2016-12-31</td>
 </tr>
 <tr>
   <td>v4.4.1</td>
@@ -119,11 +125,14 @@ beyond the LTS release.
   <td>2018-04-01</td>
 </tr>
 <tr>
-  <td>v.Next</td>
+  <td>v6.x.x</td>
   <td>2016-10-01</td>
   <td>2018-04-01</td>
   <td>2019-04-01</td>
 </tr>
 </table>
 
-<p><img src="strawmanschedule.png" alt="Strawman LTS Schedule"/></p>
+<p><img src="https://camo.githubusercontent.com/675f052419c56a583c19644d4da30cc0ff4e02bb/68747470733a2f2f636c6475702e636f6d2f6c4d48746245334e72782d3330303078333030302e706e67" alt="Strawman LTS Schedule"/></p>
+
+(note: the diagram above shows v0.12 maintenance expiring in April 2017. That
+date has been changed to December 31st, 2016.)