LibreGaming/matchbot
LibreGaming
/
matchbot
15
1
Fork 1
Code Issues Pull Requests Projects Releases 3 Activity

Document the release process and build system #10

Merged
seabass merged 2 commits from seabass/matchbot:document-builds-and-releases into master 2022-04-27 16:24:59 +02:00
Conversation 0 Commits 2 Files Changed 1 +15
1 changed files with 15 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 0a939da401 - Show all commits

15
CONTRIBUTING.md
View File

@ -59,3 +59,18 @@ An uberjar is much like a normal JAR file, but comes with all the dependencies o
This means that it can run directly on the JVM without Clojure being installed (it contains a copy of the Clojure compiler itself).
To generate an uberjar, run `clojure -T:build uber`; you should find the uberjar called something like `matchbot-x.x.x-standalone.jar` in the `target/` directory.
Please note that if you distribute an uberjar, you must not only comply with the licence of `matchbot`, but also the licences of all `matchbot`'s dependencies, both transitive and intransitive.
## Versioning and release process
### Semantic Versioning
`matchbot` uses [version 2.0.0 of the Semantic Versioning](https://semver.org/spec/v2.0.0.html) scheme, but there is still ambiguity in what exactly comprises the 'Public API' (used for determining the right part of the version to increment) for something like `matchbot`.
This 'Public API' is defined for `matchbot` as everything that is accessible by the end user or administrator of a `matchbot` instance.
For example, a change that requires the configuration file to be updated warrants a major version increment because it effects the administrator; however, a change to the structure of the internal namespaces would only require a patch level version increment because it doesn't affect either the administrator or the end user.
### Release process
At some point after a new feature has been added to `matchbot` or a bug has been fixed, a release will be made.
Once a suitable version increment for the type of changes has been determined, the `CHANGELOG.md` file at the root of the repository will be updated with release notes documenting the changes made in that version.
Then, a JAR file and a POM file will be produced using the build system (see above for more information), signed using GPG and finally uploaded to [Maven Central](https://central.sonatype.org/).
Currently this process is done by [Sebastian Crane](https://git.libregaming.org/seabass); if you would like to help with making releases, please familiarise yourself with the process (you can try everything locally except upload to Maven Central) and get in contact! 😀