rename api.md to old_api.md and update links (#1674)

README.md

@@ -34,7 +34,7 @@ Technical committee holds regular meetings, notes are held
     - [Propagators](specification/context/api-propagators.md)
   - [Baggage](specification/baggage/api.md)
   - [Tracing](specification/trace/api.md)
-  - [Metrics](specification/metrics/api.md)
+  - [Metrics](specification/metrics/new_api.md)
 - SDK Specification
   - [Tracing](specification/trace/sdk.md)
   - [Resource](specification/resource/sdk.md)

specification/glossary.md

@@ -99,7 +99,7 @@ Metrics, logs, and traces exported to telemetry backends are examples of out-of-
 
 ### Manual Instrumentation
 
-Coding against the OpenTelemetry API such as the [Tracing API](trace/api.md), [Metrics API](metrics/api.md), or others to collect telemetry from end-user code or shared frameworks (e.g. MongoDB, Redis, etc.).
+Coding against the OpenTelemetry API such as the [Tracing API](trace/api.md), [Metrics API](metrics/new_api.md), or others to collect telemetry from end-user code or shared frameworks (e.g. MongoDB, Redis, etc.).
 
 ### Automatic Instrumentation
 
@@ -150,7 +150,7 @@ Synonyms: *Instrumenting Library*.
 ### Tracer Name / Meter Name
 
 This refers to the `name` and (optional) `version` arguments specified when
-creating a new `Tracer` or `Meter` (see [Obtaining a Tracer](trace/api.md#tracerprovider)/[Obtaining a Meter](metrics/api.md#meter-interface)).
+creating a new `Tracer` or `Meter` (see [Obtaining a Tracer](trace/api.md#tracerprovider)/[Obtaining a Meter](metrics/new_api.md#meterprovider)).
 The name/version pair identifies the [Instrumentation Library](#instrumentation-library).
 
 ## Logs

specification/library-guidelines.md

@@ -129,5 +129,5 @@ guidelines on the performance expectations that API implementations should meet,
 Please refer to individual API specification for guidelines on what concurrency
 safeties should API implementations provide and how they should be documented:
 
-* [Metrics API](./metrics/api.md#concurrency)
+* [Metrics API](./metrics/new_api.md#concurrency)
 * [Tracing API](./trace/api.md#concurrency)

specification/library-layout.md

@@ -29,7 +29,7 @@ api
 
 This directory describes the API that provides in-process context propagation.
 
-### [/metrics](./metrics/api.md)
+### [/metrics](./metrics/new_api.md)
 
 This directory describes the Metrics API that can be used to record application metrics.
 

specification/metrics/README.md

@@ -28,7 +28,7 @@ Table of Contents
     * [API](#api)
     * [SDK](#sdk)
 * [Specifications](#specifications)
-  * [Metrics API](./api.md)
+  * [Metrics API](./new_api.md)
   * Metrics SDK (not available yet)
   * [Metrics Data Model and Protocol](datamodel.md)
   * [Semantic Conventions](./semantic_conventions/README.md)
@@ -106,7 +106,7 @@ SDK](../overview.md#sdk) concept concept for more information.
 
 ## Specifications
 
-* [Metrics API](./api.md)
+* [Metrics API](./new_api.md)
 * Metrics SDK (not available yet)
 * [Metrics Data Model and Protocol](datamodel.md)
 * [Semantic Conventions](./semantic_conventions/README.md)

specification/metrics/datamodel.md

@@ -147,7 +147,7 @@ OpenTelemetry fragments metrics into three interacting models:
 ### Event Model
 
 The event model is where recording of data happens. Its foundation is made of
-[Instruments](api.md), which are used to record data observations via events.
+[Instruments](new_api.md), which are used to record data observations via events.
 These raw events are then transformed in some fashion before being sent to some
 other system.  OpenTelemetry metrics are designed such that the same instrument
 and events can be used in different ways to generate metric streams.
@@ -164,12 +164,12 @@ compressed format rather than individual timeseries.
 > Note: The above picture shows how one instrument can transform events into
 > more than one type of metric stream. There are caveats and nuances for when
 > and how to do this.  Instrument and metric configuration are outlined
-> in the [metrics API specification](api.md).
+> in the [metrics API specification](new_api.md).
 
 While OpenTelemetry provides flexibility in how instruments can be transformed
 into metric streams, the instruments are defined such that a reasonable default
 mapping can be provided. The exact
-[OpenTelemetry instruments](api.md##metric-instruments) are more fully
+[OpenTelemetry instruments](new_api.md##instrument) are more fully
 detailed in the API specification.
 
 In the Event model, the primary data are (instrument, number) points, originally

specification/metrics/semantic_conventions/openmetrics-guidelines.md

@@ -45,7 +45,7 @@ See also [Metric names and labels](https://prometheus.io/docs/concepts/data_mode
 in the Prometheus data model documentation.
 
 OpenMetrics does not allow metric names to begin with a digit. OpenTelemetry's
-[instrument naming requirements](../api.md#instrument-naming-requirements) also
+[instrument naming requirements](../new_api.md#instrument-naming-rule) also
 require that the first character of a metric instrument is non-numeric.
 
 If a metric event is generated in OpenTelemetry that does not conform to this

specification/resource/sdk.md

@@ -24,7 +24,7 @@ all `Span`s produced by any `Tracer` from the provider MUST be associated with t
 
 Analogous to distributed tracing, when used with metrics,
 a resource can be associated with a `MeterProvider`.
-When associated with a [`MeterProvider`](../metrics/api.md#meter-interface),
+When associated with a [`MeterProvider`](../metrics/new_api.md#meter),
 all metrics produced by any `Meter` from the provider will be
 associated with this `Resource`.