From 773fb4a32474af1cbebb56f08d2d6155db2a61c3 Mon Sep 17 00:00:00 2001
From: "github-actions[bot]"
 <41898282+github-actions[bot]@users.noreply.github.com>
Date: Sun, 13 Sep 2026 19:24:45 +0000
Subject: [PATCH] Version packages

---
 .changeset/integer-timetable.md | 28 ----------------------------
 CHANGELOG.md                    | 29 +++++++++++++++++++++++++++++
 package.json                    |  2 +-
 3 files changed, 30 insertions(+), 29 deletions(-)
 delete mode 100644 .changeset/integer-timetable.md

diff --git a/.changeset/integer-timetable.md b/.changeset/integer-timetable.md
deleted file mode 100644
index f963714..0000000
--- a/.changeset/integer-timetable.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-"connection-scan-algorithm": major
----
-
-Scan connections held as arrays of numbers, 30 to 90 times faster.
-
-The algorithm and its classes are as they were: `toGtfsData`, `ConnectionScanAlgorithm` asking
-`ScanResults` whether each connection is reachable and better, and `JourneyFactory` building legs
-from the connection index. What they read changes. Stations are numbered, connections are parallel
-typed arrays sorted by arrival rather than an object each, `ScanResults` holds arrays indexed by
-station, and a connection or footpath is its index. A scan starts at the first connection arriving
-after the departure time rather than at midnight, stops once every destination has been reached,
-and whether each trip runs is worked out once per date by a `TripCalendar`.
-
-Over the GB rail feed, planning Tuesday 15 September, across repeated runs: 32 standard queries (the
-24 of `npm run perf` and eight more) take 3.1-3.5ms each on average rather than 115-117ms, 268
-journeys through couplings 1.7ms rather than 130ms, and 400 random station pairs 4.4-5.3ms rather
-than 170-174ms. Building takes 305-360ms rather than 570-630ms, and holds 83MB rather than 195MB. All
-1,100 answers are the same journeys 2.0.0 returns, trip for trip.
-
-`DepartAfterQuery`, `loadGtfs` and `toGtfsData` are called as before. What changes:
-
-- `new ConnectionScanAlgorithm(gtfs, new ScanResultsFactory(gtfs))` and `new JourneyFactory(gtfs)`
-- `GtfsData` holds `Connections` and `Transfers` as arrays, an `Int32Array` of interchange times, a
-  `TripCalendar`, the `trips` and a `stopTable` numbering the stations
-- `scan` returns a `ConnectionIndex` of `Int32Array`, and a `Connection` is a number: `TimetableConnection`
-  and `TransfersByOrigin` are gone, and `isTransfer` checks a leg while `isTransferConnection` checks
-  a connection
diff --git a/CHANGELOG.md b/CHANGELOG.md
index f0e426d..c3dbff0 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,34 @@
 # connection-scan-algorithm
 
+## 3.0.0
+
+### Major Changes
+
+- c03d451: Scan connections held as arrays of numbers, 30 to 90 times faster.
+  
+  The algorithm and its classes are as they were: `toGtfsData`, `ConnectionScanAlgorithm` asking
+  `ScanResults` whether each connection is reachable and better, and `JourneyFactory` building legs
+  from the connection index. What they read changes. Stations are numbered, connections are parallel
+  typed arrays sorted by arrival rather than an object each, `ScanResults` holds arrays indexed by
+  station, and a connection or footpath is its index. A scan starts at the first connection arriving
+  after the departure time rather than at midnight, stops once every destination has been reached,
+  and whether each trip runs is worked out once per date by a `TripCalendar`.
+  
+  Over the GB rail feed, planning Tuesday 15 September, across repeated runs: 32 standard queries (the
+  24 of `npm run perf` and eight more) take 3.1-3.5ms each on average rather than 115-117ms, 268
+  journeys through couplings 1.7ms rather than 130ms, and 400 random station pairs 4.4-5.3ms rather
+  than 170-174ms. Building takes 305-360ms rather than 570-630ms, and holds 83MB rather than 195MB. All
+  1,100 answers are the same journeys 2.0.0 returns, trip for trip.
+  
+  `DepartAfterQuery`, `loadGtfs` and `toGtfsData` are called as before. What changes:
+  
+  - `new ConnectionScanAlgorithm(gtfs, new ScanResultsFactory(gtfs))` and `new JourneyFactory(gtfs)`
+  - `GtfsData` holds `Connections` and `Transfers` as arrays, an `Int32Array` of interchange times, a
+    `TripCalendar`, the `trips` and a `stopTable` numbering the stations
+  - `scan` returns a `ConnectionIndex` of `Int32Array`, and a `Connection` is a number: `TimetableConnection`
+    and `TransfersByOrigin` are gone, and `isTransfer` checks a leg while `isTransferConnection` checks
+    a connection
+
 ## 2.0.0
 
 ### Major Changes
diff --git a/package.json b/package.json
index 43ef5f2..82532d2 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "connection-scan-algorithm",
-  "version": "2.0.0",
+  "version": "3.0.0",
   "description": "Connection Scan Algorithm",
   "main": "./dist/cjs/index.js",
   "types": "./dist/esm/index.d.ts",