pixelkiln 0.60.1 → 0.61.0
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/CONTRIBUTING.md +18 -2
- package/package.json +1 -1
package/CONTRIBUTING.md
CHANGED
|
@@ -73,6 +73,20 @@ wire contracts.
|
|
|
73
73
|
image. Any `website` scope is also refused a release by `releaseRules` in
|
|
74
74
|
`.releaserc.json`, so a slip is caught rather than published, but the right
|
|
75
75
|
subject keeps the changelog honest.
|
|
76
|
+
- **A change under `skills/pixelkiln/` always releases, whatever the commit
|
|
77
|
+
type says.** That directory is what the public `gfargo/skills` tap mirrors
|
|
78
|
+
on every new release tag (see [Releases](#releases)), so a `docs:`-typed
|
|
79
|
+
commit touching it — accurate framing for a human reader, since it reads as
|
|
80
|
+
documentation — would otherwise cut no release at all under the default
|
|
81
|
+
rules, and the tap would never see the change. `analyzeCommits` runs a
|
|
82
|
+
second plugin (`scripts/release-plugins/skill-release-analyzer.mjs`)
|
|
83
|
+
alongside `@semantic-release/commit-analyzer` that inspects each commit's
|
|
84
|
+
actual changed files and forces at least a patch release whenever one
|
|
85
|
+
touches `skills/pixelkiln/`, regardless of type or scope. It only ever
|
|
86
|
+
raises the release semantic-release would otherwise cut, never lowers or
|
|
87
|
+
blocks one, so there is no commit-subject convention to remember here —
|
|
88
|
+
just don't remove the plugin from `.releaserc.json` (`test:release` fails
|
|
89
|
+
if it is missing).
|
|
76
90
|
- Add regression coverage for bug fixes and behavior coverage for new public
|
|
77
91
|
options or exports.
|
|
78
92
|
- Update README/help text and focused docs in the same change as user-facing
|
|
@@ -169,5 +183,7 @@ A failed release opens an issue labelled `semantic-release`, which the next
|
|
|
169
183
|
successful run closes. That label must exist in the repository or the reporting
|
|
170
184
|
step itself fails with a validation error and hides the original failure.
|
|
171
185
|
|
|
172
|
-
See the website scoping rule
|
|
173
|
-
|
|
186
|
+
See the website scoping rule and the `skills/pixelkiln/` release-forcing
|
|
187
|
+
plugin under [change guidelines](#change-guidelines) for the two things that
|
|
188
|
+
change whether a release happens at all, independent of the conventional
|
|
189
|
+
commit type on its own.
|