Add v1.18.0, drop v1.4.0 (#84)

versioned_docs/version-v1.4.0/README.md → versioned_docs/version-v1.18.0/README.md

@@ -42,14 +42,14 @@ that underlie the Zed formats.
 [sequential (ZNG)](formats/zng.md), [columnar (VNG)](formats/vng.md),
 and [human-readable (ZSON)](formats/zson.md) formats that all adhere to the
 same abstract Zed data model.
-* A [Zed lake](commands/zed.md) is a collection of optionally-indexed Zed data stored
-across one or more [data pools](commands/zed.md#14-data-pools) with ACID commit semantics and
+* A [Zed lake](commands/zed.md) is a collection of Zed data stored
+across one or more [data pools](commands/zed.md#data-pools) with ACID commit semantics and
 accessed via a [Git](https://git-scm.com/)-like API.
-* The [Zed language](language/README.md) is the system's dataflow language for performing
+* The [Zed language](language/README.md) is the system's pipeline language for performing
 queries, searches, analytics, transformations, or any of the above combined together.
-* A  [Zed query](language/overview.md#1-introduction) is a Zed script that performs
+* A  [Zed query](language/overview.md) is a Zed script that performs
 search and/or analytics.
-* A [Zed shaper](language/overview.md#10-shaping) is a Zed script that performs
+* A [Zed shaper](language/shaping.md) is a Zed script that performs
 data transformation to _shape_
 the input data into the desired set of organizing Zed data types called "shapes",
 which are traditionally called _schemas_ in relational systems but are
@@ -62,7 +62,7 @@ is the best way to learn about `zq` in depth.
 All of its examples use `zq` commands run on the command line.
 Run `zq -h` for a list of command options and online help.
 
-The [Zed Lake documentation](commands/zed.md)
+The [Zed lake documentation](commands/zed.md)
 is the best way to learn about `zed`.
 All of its examples use `zed` commands run on the command line.
 Run `zed -h` or `-h` with any subcommand for a list of command options
@@ -92,16 +92,12 @@ or other third-party services to interpret the lake data.
 Once copied, a new service can be instantiated by pointing a `zed serve`
 at the copy of the lake.
 
-Functionality like indexing, data compaction, and retention are all
-API-driven.
+Functionality like [data compaction](commands/zed.md#manage) and retention are all API-driven.
 
 Bite-sized components are unified by the Zed data, usually in the ZNG format:
 * All lake meta-data is available via meta-queries.
 * All like operations available through the service API are also available
 directly via the `zed` command.
-* Search indexes and aggregate partials are all just ZNG files and you can
-learn about the Zed lake by simply running `zq` on the various ZNG files
-in a cloud store.
 * Lake management is agent-driven through the API.  For example, instead of complex policies
 like data compaction being implemented in the core with some fixed set of
 algorithms and policies, an agent can simply hit the API to obtain the meta-data