https://github.com/maxicorrea/java-spring-boot-semantic-versioning

Java Spring Boot Semantic Versioning
https://github.com/maxicorrea/java-spring-boot-semantic-versioning

java java-spring java-springboot rest-api restful-api semantic-release semantic-release-plugin semantic-versioning

Last synced: about 1 month ago
JSON representation

Java Spring Boot Semantic Versioning

• Host: GitHub
• URL: https://github.com/maxicorrea/java-spring-boot-semantic-versioning
• Owner: MaxiCorrea
• Created: 2024-10-24T19:42:45.000Z (about 2 months ago)
• Default Branch: master
• Last Pushed: 2024-10-25T15:55:42.000Z (about 2 months ago)
• Last Synced: 2024-10-26T06:55:10.676Z (about 2 months ago)
• Topics: java, java-spring, java-springboot, rest-api, restful-api, semantic-release, semantic-release-plugin, semantic-versioning
• Language: Java
• Homepage:
• Size: 37.1 KB
• Stars: 1
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md

Awesome Lists containing this project

README

        
# Java Spring Boot Semantic Versioning

### Example Project: Using Semantic Versioning with Spring Boot

This repository is an example of using Semantic Versioning in a Spring Boot application, following the Angular Commit Messages conventions and using semantic-release for automated version management.

### Commit message format

**semantic-release** uses the commit messages to determine the consumer impact of changes in the codebase.

Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publishes the release.

By default, **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format).

The commit message format can be changed with the [`preset` or `config` options](docs/usage/configuration.md#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.

Tools such as [commitizen](https://github.com/commitizen/cz-cli) or [commitlint](https://github.com/conventional-changelog/commitlint) can be used to help contributors and enforce valid commit messages.

The table below shows which commit message gets you which release type when `semantic-release` runs (using the default configuration):

| Commit message                                                                                                                                                                                   | Release type                                                                                                    |

| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- |

| `fix: stop graphite breaking when too much pressure applied`                                                                                                                             | ~~Patch~~ Fix Release                                                                                           |

| `feat: add 'graphiteWidth' option`                                                                                                                                                       | ~~Minor~~ Feature Release                                                                                       |

| `perf: remove graphiteWidth option`

`BREAKING CHANGE: The graphiteWidth option has been removed.`
`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release 
 (Note that the `BREAKING CHANGE: ` token must be in the footer of the commit) |