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 `develop`.
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 `dev`.
# Creating normal test cases
...
...
@@ -73,23 +73,23 @@ The test then ensures, that both output grammars are identical.
Important information:
- Currently, we are publishing to a private Nexus Maven repository only.
- We are using [git-flow][git-flow], so only new merge requests are considered for releases to appear in the `master` branch.
- We are using [git-flow][git-flow], so only new merge requests are considered for releases to appear in the `main` branch.
- The version is set in the configuration file [RelASTVersion.properties][RelASTVersion.properties].
The workflow:
1) Finish your work with the current feature(s) and merge those back in `develop`.
1) Finish your work with the current feature(s) and merge those back in `dev`.
1) Choose a new version number `$nextVersion` depending on the introduced changes **following [semantic versioning][semantic-versioning]**.
1) Create a new release branch named `release/$nextVersion` and switch to this branch.
1) Set the version number in the config file calling `./gradlew newVersion -Pvalue=$nextVersion`
1) Commit this change.
1) (Optional) Build a new jar file calling `./gradlew jar` (this is automatically called in the publish step and only used to test the newly set version number)
1) Check, if everything works as planned, e.g., version number is picked up when running the application with `--version`, and all test succeed.
1) Merge the release branch into `master` (using a merge request) and also back into `develop`.
1) Merge the release branch into `main` (using a merge request) and also back into `dev`.
1) Delete the release branch.
1) [Create a new release][create-release]. Choose the following:
-*Tag name*: the chosen version number
-*Create from*: leave the default `master`
-*Create from*: leave the default `main`
-*Message*: "Version " and the chose version number
-*Release notes*: list the (important) changes compared to the last release, prepend a link to the built jar using the line `[:floppy_disk: publish-relast-poc-$nextVersion.jar](/../../../-/jobs/$jobNumber/artifacts/raw/build/libs/publish-relast-poc-$nextVersion.jar?inline=false)` replacing `$jobNumber` with the `jar` job of the pipeline run after the merge request, and `$nextVersion`
1) Publish the built jar to the maven repository calling `./gradlew publish`
