stitchkit 0.90.6 → 0.90.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +20 -0
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -15,6 +15,26 @@ additive**; the first breaking change landed in 0.10.0. Grep the file for
|
|
|
15
15
|
|
|
16
16
|
## [Unreleased]
|
|
17
17
|
|
|
18
|
+
## [0.90.7] — 2026-09-21
|
|
19
|
+
|
|
20
|
+
### Fixed
|
|
21
|
+
|
|
22
|
+
- Release workflows now remain safely rerunnable after another package in the
|
|
23
|
+
same train reaches npm, candidate registration stays repeatable after
|
|
24
|
+
publication, and registry polling tolerates normal multi-minute processing.
|
|
25
|
+
- **A release train may no longer publish the framework together with the
|
|
26
|
+
starter that has to pin it.** The starter's lockfile is written by an install,
|
|
27
|
+
so it can only resolve a version npm already serves; a train doing both at
|
|
28
|
+
once states two things that cannot both hold, and the starter it publishes is
|
|
29
|
+
a version behind from its first minute. `create-stitchkit@0.6.1` shipped that
|
|
30
|
+
way. The refusal is narrow — a starter deliberately targeting an older minor
|
|
31
|
+
still rides along with a new one — and it reads the train file rather than the
|
|
32
|
+
registry, so every attempt at the same commit gets the same answer.
|
|
33
|
+
- **The starter lockfile gate now also refuses a pin npm does not serve.** Its
|
|
34
|
+
staleness comparison only ever looked downward, so a lockfile naming a version
|
|
35
|
+
above the newest published one passed every check and left the scaffold to die
|
|
36
|
+
at `bun install` on the consumer's machine.
|
|
37
|
+
|
|
18
38
|
## [0.90.6] — 2026-09-20
|
|
19
39
|
|
|
20
40
|
### Added
|
package/package.json
CHANGED