NB! This is still in pre-release, thus breaking changes between minor versions are to be expected until first stable release. At the same time, the functionality is covered extensively with tests, and I'm also using the gradle plugin in my other projects (see e.g. kotlin-faker/settings.gradle.kts), so it's possible to use both the libraries and the gradle plugin already.
This repo contains three modules which can be used separately:
io.github.serpro69:semver.kt-spec- a kotlin implementation of semver specio.github.serpro69:semver.kt-release- provides functionality for automated release versioning (based on git tags) which adheres to semver rulesio.github.serpro69.semantic-versioninga gradle plugin for automated semantic versioning during builds
I've been using the gradle-semantic-build-versioning plugin for my gradle-based projects, and it works great for the most part. Unfortunately the project has not been maintained since late 2019, the author does not reply to open issues, and gradle has pretty strict rules on publishing forks of plugins. Therefore, I've decided to re-write my own plugin using Kotlin.
I like monorepo approach when it makes sense, so I decided to keep all the necessary code in one single repo. At the same time I think it could be useful to publish the "core" APIs (semver-spec and semver-release) as separate artifacts instead of having all the code within the plugin sources. This would allow to easily add a similar maven plugin in the future provided there's interest, using the same APIs. And at the same time these APIs could also be useful to someone else as standalone artifacts which can be used in other projects?
I've found that alternatives do not really satisfy my needs and wants. For example, the popular semantic-release works great for JS projects, but is kind of a pain when used in JVM-based projects.
In addition, I want to expand on the idea of avoiding hardcoded versions in build files as this seems completely unnecessary since versions are also stored as git objects (tags, or sometimes branches). This is something that I don't see very often in other existing tools which tend to write versions to the build files, and which was one of the things that I really liked about the aforementioned 'gradle-semantic-build-versioning' plugin.
Each of the modules can be used separately either as a library by declaring a dependency or as a gradle plugin. For module-specific usage details see modules' respective README files.
- java >= 8
- kotlin >= 1.6
- gradle >= 7.5 (for
:semantic-versioningplugin)