Skip to content

Commit

Permalink
Updated A Round Of Applause Semantic Release For The Clapper Component
Browse files Browse the repository at this point in the history
  • Loading branch information
chriswilty authored and Siteleaf committed Oct 16, 2024
1 parent df13ee0 commit 2058f18
Showing 1 changed file with 2 additions and 2 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -63,9 +63,9 @@ Take a look at [semantic-release's own release page for v23.0.0](https://github.

### Prepare

This step is implemented by [npm plugin][npm-plugin] and [GitHub plugin][github-plugin], to prepare bundles for release - a tarball for the npm package, and zip and tarball of source code for the GitHub release. However, there are important differences in the bundles generated for the two.
This step is implemented by [npm plugin][npm-plugin] and [GitHub plugin][github-plugin], to prepare bundles for release - a tarball for the npm package, and zip and tarball of source code for the GitHub release. However, there are important differences between the bundles generated for the two.

It is [recommended not to increment version number](https://semantic-release.gitbook.io/semantic-release/support/faq#making-commits-during-the-release-process-adds-significant-complexity) in the GitHub repo during a release, as that adds a lot of complexity: the release process will need permissions to create and push a commit, which is likely to be restricted on the release branch. Instead, you will see in the [applause-button package.json](https://github.com/ColinEberhardt/applause-button/blob/master/package.json#L4) we have version set to "0.0.0-semantically-managed", to indicate we don't need to worry about version numbering during development. This is a key tenet of semantic versioning: let code changes determine release numbering, rather than working towards pre-determined releases.
It is [recommended not to increment version number](https://semantic-release.gitbook.io/semantic-release/support/faq#making-commits-during-the-release-process-adds-significant-complexity) in the GitHub repo during a release, as that adds a lot of complexity: the release process will need permissions to create and push a commit, which is likely to be restricted on the release branch. Instead, you will see in the [applause-button package.json](https://github.com/ColinEberhardt/applause-button/blob/master/package.json#L4) we have version set to `0.0.0-semantically-managed`, to indicate we don't need to worry about version numbering during development. This is a key tenet of semantic versioning: let code changes determine release numbering, rather than working towards pre-determined releases.

However, we do need our package in npm to have the correct version number, so the [npm plugin][npm-plugin] makes that change locally before creating the tarball, using the version number calculated in the Analyze Commits step. Additionally, we have an npm script (`prepack`) which runs the build before packaging, to generate production-ready JavaScript and CSS files. Therefore the package tarball also contains a dist folder with these assets, which the GitHub source bundles do not have.

Expand Down

0 comments on commit 2058f18

Please sign in to comment.