# Process to contribute new features or to fix bugs
To propose a new feature, or to report a bug, first [create an issue][create-issue] and add labels accordingly.
Working on such issues is done by creating a merge request from the issue page, which 1) creates a new branch to work on, and 2) creates a new WIP merge request for the new branch.
Once done (and new tests are written to ensure, a bug is really fixed, and the feature does the right thing), the merge request will be accepted and merged into `master`.
# Creating normal test cases
A test usually defines a grammar, optionally some attributes and a Test class.
@@ -67,3 +73,13 @@ Furthermore, empty lines, lines starting with `//` and the order of the error me
Currently, there is one test to test whether the output of RelAST is a valid input for RelAST and produces the same output again.
To achieve this, there two Gradle tasks. The first produces the usual `.ast` and `.jadd` files, whereas the second task takes the `.ast` as input.
The test then ensures, that both output grammars are identical.
# Publishing
To publish a new version, the following needs to be done:
1) Create a new annotated tag with an appropriate version number increase (major, minor, patch) described in [semantic versioning](https://semver.org/)
2) If not already present, create a new file `gradle.properties` with two entries `repoUser` and `repoPassword` for our Nexus repository.
3) Run `./gradlew publish -PwithNewVersion` (maybe also adding ` -PasSnapshot` to create a SNAPSHOT release)