This section will show you how to properly create a release for the app.
## Conventional commit
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.
...
...
@@ -18,33 +16,40 @@ The commit message should be structured as follows:
The commit contains the following structural elements, to communicate intent to the consumers of your library:
* fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
* feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
* BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
* types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
***fix**: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
***feat**: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
***BREAKING CHANGE**: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
* types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
* footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.
## standard-version
Find out more [here](https://www.conventionalcommits.org/en/v1.0.0/#summary)
## Release Ecolyo with Standard-version
Standard-version is library javascript that allow to handle easily tags and changelog file.
Just run the following command in order to create a release tag, bump package.json version and update changelog file.
To create a new release, you have to :
1. the following command in order to create a release tag, bump package.json version and update changelog file.
First manually bump the manifest version (for cozy apps) in manifest.webapp and use the following commit format : 'bump manifest version to X.X.X'
Then launch the following command :
1. checkout on the branch `dev` and bump the version number in `manifest.webapp`. Use the following commit format: 'bump manifest version to X.X.X'
2. then run
```bash
yarn run release ----release-as X.X.X # replace with version number (ex: 1.2.0)
```
Once it is done execute to push the tagged commit :
3. once the command has finished, push with
```
git push --follow-tags origin dev
```
:warning: Do not push with VS Code
Finally, add release notes in gitlab in your project -> repository -> [tags](https://forge.grandlyon.com/web-et-numerique/llle_project/ecolyo/-/tags) -> **edit release notes**
Don't forget to add release notes in gitlab in *your project -> repository -> tags -> edit release notes *
You can copy paste the last changelogs in the release notes.
You can copy paste the last changes in [CHANGELOG.MD](https://forge.grandlyon.com/web-et-numerique/llle_project/ecolyo/-/blob/dev/CHANGELOG.md)
### Annotated Tags
...
...
@@ -74,4 +79,4 @@ This command will annotate an existing tag (v2.1.3 with chore(release): 2.1.3 he
