Build release workflow for after 1.0.0

[jguddas]

Description

• release changes for individual js packageks (major, minor, patch)
• mark icon removal as major
• mark new icon as minor
• mark significant icon changes as minor
• mark optimizations as patch
• mark icon rename while keeping the old name as alias as patch
• mark icon rename while not keeping the old name as alias as major
• mark alias removal as major

Dreaming of doing so automatically.

Just brainstorming… We could use somthing like changesets, and require a changeset when people edit /packages, and autogenerate one when people edit /icons

[life4aiur]

This is a good plan, the one thing I have an issue with is the last bullet point. "mark icon rename while keeping the old name as alias as patch"

A rename would break the API/contract for someone consuming the icons and therefore be a breaking change. If you are consuming something like a svg, and you take a patch, you would expect that svg to still be there not just removed and added as an alias to another svg.

This puts the onus on consumers to then dig through aliases when taking a patch to find where their icon went.

[jguddas]

I'm too tiered to explain the alias mechanism right now, but this is what ChatGPT says about it:

You are assuming that a rename automatically implies the removal of the original SVG. Renaming can be implemented in various ways, and it doesn't always involve removing the original resource. Alias mechanisms or redirects can be used to ensure backward compatibility.

[ericfennis]

Idea:

Starting with commit/PR name prefixes. This can be simply done by prefixing PR titles by telling what the PR is including. When PR is merged all commits in PR will be squashed and get the name of the PR.

With certaint types and scopes, we determine what we do. Like @jguddas describes in the description. This is based on: https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format

Type

Must be one of the following:

• fix: A bug fix [PATCH]
• feat: A new feature [MINOR]
• icon: A new icon [MINOR]
• meta: Changes in metadata
• build: Changes that affect the build system or external dependencies
• ci: Changes to our CI configuration files and scripts (Github actions)
• site: Changes to the website
• docs: Documentation only changes
• perf: A code change that improves performance [PATCH]
• refactor: A code change that neither fixes a bug nor adds a feature
• test: Adding missing tests or correcting existing tests
• revert: Reverting code changes [PATCH]
• style: Changes that do not affect the meaning of the code (code formatting)
• test: Adding missing or correcting existing tests

Scope

The scope should be the name of the icon or a NPM package. The following is the list of supported scopes:

• {name of an icon}
• {name of a npm package}
• no-release (which won't trigger a release, see Semantic release repo)

PR titles/commit messages

PR titles / commit messages that are merged to the repo should use this format. (When merging a PR with the format in the title this will automatically added in the commit message)

Examples:

• Add a new icon
  • icon(arrow-up-down): Add arrow-up-icon
  • icon(arrow-up|arrow-down): Adds arrow icons (multiple)
• Refactoring/optimizing existing icons
  • refactor(arrow-up-down): Optimize arrow-up-icon
• Updating metadata
  • meta(arrow-up-down): Adding contributors
• Add a new feature
  • feat(lucide-react): Adding a feature to Lucide React

We also could automatically change the title of the PR with GitHub actions to fix wrong titles.

Release rules

Default release rules when pushing to the main branch. Only the following types will execute a release:

• fix
• feat
• icon
• revert
• perf

Supporting packages and GitHub actions we can use

• Semantic Release, https://github.com/semantic-release/semantic-release
• Commit Analyzer. To https://github.com/semantic-release/commit-analyzer?tab=readme-ov-file#options
• Commit Lint, to check PR titles: https://commitlint.js.org/#/reference-rules