Skip to content
This repository has been archived by the owner on Feb 26, 2023. It is now read-only.

Latest commit

 

History

History
139 lines (74 loc) · 3.6 KB

release-workflow.lnjwx.sw.md

File metadata and controls

139 lines (74 loc) · 3.6 KB
id name file_version app_version
lnjwx
Release Workflow
1.0.2
0.8.6-2

Swimm UI uses Semantic Release to automate releases when making changes to the library.

We use Conventional Commits as the format of the commits, to know which version to release.


Semantic Versioning


Semantic versioning is used to be able to identify the essence of the changes, when upgrading to a new version. The version number is structured as: major.minor.patch , which semantically means: BREAKING.features.fixes .


Writing Conventional Commits


The structure should be the following:


type(scope?): subject

body?

footer?

Type


The type can be any of the following types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert.


Scope


The scope is optional. It meant to identify the area or module that was changes. This can be a name of a component, a name of a module, or anything else that will help identify the part of the code/library that was changed.


Subject


This is the short commit message header.


Body and Footer


Both are optional and are meant to provide further details about the commit.


Upgrading The Version

The only commit types that trigger a new version are:


  • fix - increases the patch version (bug fixes)

  • feat - increases the minor version (new features)

  • BREAKING CHANGE in the description - increases the major version (breaking changes)


Other commit types will NOT release a new version as they will not affect anything for the users of the package. They will be automatically included in the next release. It means that if you change for example some color variable, and use a different commit rather than fix/feat, a new version will not be released and you won’t be able to see the changes.


Commitlint

To avoid misusage and wrong commit message, we use Commitlint as a Git Hook to lint the commit messages.

Commit Examples

Let’s say we are currently in version 1.1.1

This kind of commit will upgrade the patch number and trigger a release for 1.1.2:

  • Fixing a color value: fix(colors): change color for —bg-color

These kind of commits will upgrade the minor number and trigger a release for 1.2.0:

  • Adding a feature to a component: feat(Icon): add hover state

This kind of commit will upgrade the major number and trigger a release for 2.0.0:

  • Upgrading to Vue 3 with breaking changes:

    feat(deps): upgrade to vue 3

BREAKING CHANGES: peer dependency updated to vue 3

    or if appropriate, it can be shortened to:

    feat(deps)!: upgrade to vue 3

These kind of commits will NOT change the version number and will NOT trigger a release:

  • Adding a new test: test(Action): test button click

  • Adding a step to the CI: ci(commitlint): add commitlint to the CI

  • Changing description in package.json: chore(package): change description

  • Refactor a component (without changing it’s API): refactor(Action): re-write with composition API - version remains 1.1.1

  • Use prettier on a file: style(Icon): prettier (notice it’s not CSS style, but code style)

  • Adding components to Vuepress Catalog: docs: add Icon variations


This file was generated by Swimm. Click here to view it in the app.