Release Prep

.github/workflows/release.yml

@@ -48,6 +48,6 @@ jobs:
 
       - run: npm i
       - run: npm test
-      - run: npm publish --provenance --access public --tag alpha
+      - run: npm publish --provenance --access public
         env:
           NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

CHANGELOG.md

@@ -5,7 +5,7 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/) and this
 project adheres to [Semantic Versioning](http://semver.org/).
 
-## [0.16.0] - 2026-08-??
+## [0.16.0] - 2026-08-24
 
 This release marks our first release as a Prometheus subproject.
 

README.md

@@ -14,57 +14,12 @@ npm install @prometheus-io/client
 This package was previously published as `prom-client`. See the
 [CHANGELOG](CHANGELOG.md) for the breaking changes involved in upgrading.
 
-## Usage
+## API
 
 See example folder for a sample usage. The library does not bundle any web
 framework. To expose the metrics, respond to Prometheus's scrape requests with
 the result of `await registry.metrics()`.
 
-### Usage with Node.js's `cluster` or Worker module
-
-Note: the Prometheus client now also supports worker threads, with much the same
-constraints as cluster workers. See `example/worker.js`.
-
-Node.js's `cluster` module spawns multiple processes and hands off socket
-connections to those workers. Returning metrics from a worker's local registry
-will only reveal that individual worker's metrics, which is generally
-undesirable. To solve this, you can aggregate all of the workers' metrics in the
-master process. See `example/cluster.js` for an example.
-
-Instantiate `ClusterRegistry` before branching on `cluster.isPrimary`, as shown
-in the example. Its constructor installs the appropriate IPC listener in each
-process; if only the primary creates it, workers cannot answer aggregation
-requests and `clusterMetrics()` times out.
-
-Default metrics use sensible aggregation methods. (Note, however, that the event
-loop lag mean and percentiles are averaged, which is not perfectly accurate.)
-Custom metrics are summed across workers by default. To use a different
-aggregation method, set the `aggregator` property in the metric config to one of
-'sum', 'first', 'min', 'max', 'average' or 'omit'. (See `lib/metrics/version.js`
-for an example.)
-
-If you need to expose metrics about an individual worker, you can include a
-value that is unique to the worker (such as the worker ID or process ID) in a
-label. (See `example/server.js` for an example using
-`worker_${cluster.worker.id}` as a label value.) But this will result in a high
-cardinality situation, which the Aggregator is generally meant to avoid.
-
-Metrics are aggregated from the global registry by default. To use a different
-registry, call
-`client.AggregatorRegistry.setRegistries(registryOrArrayOfRegistries)` from the
-worker processes.
-
-#### Process Lifecycle
-
-The `shutdown()` method is provided to help cleanly shut down the application while
-metrics calls are pending. In the future this will also help with workers that are
-short-lived or need to be restarted.
-
-Please also see [The Workers Readme](Workers.md) for special notes on handling workers
-that do not survive for the entire run time of the application.
-
-## API
-
 ### Default metrics
 
 There are some default metrics recommended by Prometheus
@@ -652,6 +607,49 @@ in each GC sweep are kept in a separate module:
 https://github.com/SimenB/node-prometheus-gc-stats. (Note that that metric may
 no longer be accurate now that v8 uses parallel garbage collection.)
 
+### Usage with Node.js's `cluster` or Worker module
+
+Note: the Prometheus client now also supports worker threads, with much the same
+constraints as cluster workers. See `example/worker.js`.
+
+Node.js's `cluster` module spawns multiple processes and hands off socket
+connections to those workers. Returning metrics from a worker's local registry
+will only reveal that individual worker's metrics, which is generally
+undesirable. To solve this, you can aggregate all of the workers' metrics in the
+master process. See `example/cluster.js` for an example.
+
+Instantiate `ClusterRegistry` before branching on `cluster.isPrimary`, as shown
+in the example. Its constructor installs the appropriate IPC listener in each
+process; if only the primary creates it, workers cannot answer aggregation
+requests and `clusterMetrics()` times out.
+
+Default metrics use sensible aggregation methods. (Note, however, that the event
+loop lag mean and percentiles are averaged, which is not perfectly accurate.)
+Custom metrics are summed across workers by default. To use a different
+aggregation method, set the `aggregator` property in the metric config to one of
+'sum', 'first', 'min', 'max', 'average' or 'omit'. (See `lib/metrics/version.js`
+for an example.)
+
+If you need to expose metrics about an individual worker, you can include a
+value that is unique to the worker (such as the worker ID or process ID) in a
+label. (See `example/server.js` for an example using
+`worker_${cluster.worker.id}` as a label value.) But this will result in a high
+cardinality situation, which the Aggregator is generally meant to avoid.
+
+Metrics are aggregated from the global registry by default. To use a different
+registry, call
+`client.AggregatorRegistry.setRegistries(registryOrArrayOfRegistries)` from the
+worker processes.
+
+#### Process Lifecycle
+
+The `shutdown()` method is provided to help cleanly shut down the application while
+metrics calls are pending. In the future this will also help with workers that are
+short-lived or need to be restarted.
+
+Please also see [The Workers Readme](Workers.md) for special notes on handling workers
+that do not survive for the entire run time of the application.
+
 ## Notes
 
 ### Hot Reloading

package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@prometheus-io/client",
-	"version": "0.16.0-alpha.1",
+	"version": "0.16.0",
 	"description": "Client for prometheus",
 	"main": "index.js",
 	"files": [