Naming convention

File Extension of the Patch File

...

We have only ONE patch file for all patches of per release. The naming structure of the patch file has to look like this:
patch-<date-of-release>-<releaseVersion>.zip joc.[VERSION]-patch[PATCH_VERSION].war
where the date has the format YYYYMMdd
Example: patch-20200402-joc.1.13.3-patch1.zipwar

The patch file has to have the same structure as the joc.war file for all front end stuff i.e. for all files outside the WEB-INF folder.
The WEB-INF folder contains only one jar and the version.json
- ./lib/_patch-<releaseVersion>.jar (the leading underline is important to provide that this jar is loaded at first.
- ./classes/version.json

...

This jar contains only class files which were changed because of an issue.
All changed class files based on the Git-Tag of the release which is patched.
For this a new branch with the name "patch-<releaseVersion>" is created starting on the Git-Tag of the release if it doesn't already exist.
- Select Git-Tag (e.g. v1.13.3) in Git Extensions
- Click on "Create New Branch" of the context menu
- Type the name in the following dialog and push the button.
If the patch branch already exist then further changes continue in the branch
A patch branch is never merged into the snapshot branch and vice versa
A patch branch can be merged into another patch branch
For a local build of the own changes it is strongly reccommended that
- all patch branches are checked out
- all revisions of the Release-Git-Tag are checked out where a patch branch doesn't exist
Steps after local build:
- Download current patch file from download.sos-berlin.com
- Extract _patch-<releaseVersion>.jar
- Add or update the class files.
- Create _patch-<releaseVersion>.jar
Hint to avoid duplicate work between snapshot branch and patch branch using Git Extensions
- checkout patch branch
- select commit in snapshot branch where the changes are already made
- Goto "File Tree" tab, select changed java file and use "save as" to copy the changes in the patch branch
- In ~90% of all cases is that all what you need particularly the files were untouched since last release.

This file is read during the login and the "version" is logged in the JOC log.
This file is edited to know which exact version (including the patches) the user has.
- The "version" contains the Jira-Tickets
- The "date" contains the creation date of the patch file.

Code Block

title	Example

{
  "version":"1.13.3 Patch JOC-877, JOC-880, JOC-892",
  "gitHash":"188987909bb722a8b1a0bd021f51e12d0c8ae494",
  "date":"2020-02-21"
}