anchor.diff:  
   [source,js]
   ----
  -PUT twitter?include_type_name=true <1>
  +PUT twitter
   {
     "mappings": {
       "_doc": {
         "properties": {
  -        "type": { "type": "keyword" }, <2>
  +        "type": { "type": "keyword" }, <1>
           "name": { "type": "text" },
           "user_name": { "type": "keyword" },
           "email": { "type": "keyword" },
  
positive.code: // NOTCONSOLE
  
  [float]
  === Use `include_type_name=false` to prepare for upgrade to 8.0
  
  Index creation and mapping APIs support a new `include_type_name` url parameter 
  starting with version 6.7. It will default to `true` in version 6.7, default to
  `false` in version 7.0 and will be removed in version 8.0. When set to `true`, 
  this parameter enables the pre-7.0 behavior of using type names in the API.
  
  See some examples of interactions with Elasticsearch with this option turned off:
  
  [float]
  ==== Index creation
  
  [source,js]
  --------------------------------------------------
  
negative.code: an index that doesn't exist yet, the template is always honored. This is
  usually not a problem due to the fact that typeless index calls work on typed
  indices.
  
  [float]
  ==== Mixed-version clusters
  
  In a cluster composed of both 6.7 and 7.0 nodes, the parameter
  `include_type_name` should be specified in indices APIs like index
  creation. This is because the parameter has a different default between
  6.7 and 7.0, so the same mapping definition will not be valid for both
  node versions.
  
  Typeless document APIs such as `bulk` and `update` are only available as of
  7.0, and will not work with 6.7 nodes. This also holds true for the typeless
  versions of queries that perform document lookups, such as `terms`.
  