edfcore 0.4.245 → 0.4.247

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.4.245";
+export declare const VERSION = "0.4.247";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.245';
+export const VERSION = '0.4.247';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,34 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.4.247
+
+- **Added** documentation for the three envelope result types, taking the recorded undocumented
+  list from eight to five. `readEnvelope` resolves to `EdfEnvelopeChunk[]` and every page showed
+  `chunk.signals[0].min` without naming what `chunk` is, so anyone writing a plotting function
+  that takes one had to read the `.d.ts`. `api-helpers.md` now gives `EdfEnvelopeChunk` and
+  `EdfEnvelopeSignal` field tables, and says the thing that is easy to get wrong: `bucketCount` is
+  buckets in the grid whether filled or not, `readEnvelope` clamps it to the densest signal's
+  sample count and `readEnvelopeAtResolution` deliberately does not, and `counts` — not `min` and
+  `max` — is what answers whether a bucket holds anything. `EdfPhysicalEnvelope` is named under
+  physical units, with why it is a type of its own.
+
+## 0.4.246
+
+- **Changed** a release to be one commit instead of two. `scripts/release.mjs` refused a dirty
+  tree, so every version cost the work commit plus a `Release vX` on top of it — the day that
+  produced 0.4.150 through 0.4.244 put 193 commits on `main` for 94 versions. The precondition's
+  stated reason was that a release must match a real commit, and that holds either way, because
+  the script makes the commit itself; it still refuses to run with anything already committed but
+  unpushed. Leave the work uncommitted, write the changelog entry, and pass `-m` with the subject
+  line. A clean tree still releases the bump alone under `Release vX`.
+- **Fixed** the failure path that would have made this dangerous. On a failed check the script
+  restored the version files with `git checkout HEAD --`, which was right while the tree had to be
+  clean and is destructive now that it holds the release: `package.json` is a file releases
+  routinely change — 0.4.225 and 0.4.233 both edited its scripts — and checking it out of HEAD
+  would have discarded that work silently, in the name of undoing a bump. The three files are
+  captured in memory before the bump and written back from there.
+
 ## 0.4.245
 
 - **Corrected** the note in `scripts/release.mjs` that tells you how to audit changelog headings

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.245",
+  "version": "0.4.247",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.245';
+export const VERSION = '0.4.247';