Readme: Add a new readme for how to make a release.

README-RELEASE.md

@@ -0,0 +1,80 @@
+# Readme for making releases in DAMAP
+For each realese, basically we make a pull request and with the changes we made we can create a tag.\
+We can create the tag on the command line or directly in the UI on github.\
+We only push a tag when it is merged, otherwise it will push the release even though it is not merged yet.
+
+### For versioning the release.
+To know what the next version should be, we use semantic versioning 2.0.0 (https://semver.org/).\
+Short explanation of semantic versioning: it consists of three numbers x.y.z.\
+The z is like a patch, basically bug fixes or really minor changes that make the backend compatible.\
+
+The y is when we add new features that are backwards compatible. They are implemented in a way that a custom implementation does not have to change anything, then we can change the y number in the version.\
+
+The x is the mayor is when we do breaking changes, for example when we have some kind of API and now the all route shift example: api/old-path -> api/new-path. This is a breaking change because the implementation may break when we update. other example is when we update dependencies and the instances have to do it manually, this is a breaking change.
+
+The first version number will override the smallest. For example, if we need to increase the y and the z, we just increase the y and set the z to 0.
+The goal is to keep breaking changes to a minimum.
+
+## For create a new release in the backend
+
+Take a new branch (release) and update the pom.xml file and change the version tag. ![pom.xml file - old version](doc/screenshots/release-readme/pomxml-old-version.png)
+In this example, based on semantic versioning, we are releasing minor changes.![minor upgrade version](doc/screenshots/release-readme/pomxml-new-version.png)
+
+Then we have to do two commits, first we commit the versioning and then we have to create another commit and update it again and set a SNAPSHOT. ![SNAPSHOT](doc/screenshots/release-readme/snapshot-version.png)
+The SNAPSHOT here is a java thing that indicates that this is a dev version, indicates that things may break in the dev version and update at your own risk.
+
+_Note: As we have automatic release since we merged with next. The snapshot version can be updated at any time, but for production releases there should only be one release._
+
+Push the commits and open a new pull request.
+Since we are changing the pom.xml file in both commits to github, only the most recent will show up, so we need to go into the commit release itself, and check that it is being changed correctly.
+![commit release change](doc/screenshots/release-readme/commit-version.png)
+
+### For command line
+After the pipeline went fine, and we get an approval when it merges, we can log a tag from the command line using
+1. git log
+2. Copy the identifier of the commit we want to tag
+3. Then **git tag v4.2.0 commitID** and then push the tag.
+
+### Create a tag from github
+1. Go to the code on github and on the right side there is a title _Releases_, click on it.
+   ![alt text](doc/screenshots/release-readme/releases-button.png)
+2. Now we are in another window where we can see a tab _Draft a new release_, we click on it.  ![alt text](doc/screenshots/release-readme/draf-release.png)
+3. Now in the _Target_ tab we can select a recent commit and choose the commit for our new release. ![alt text](doc/screenshots/release-readme/commit-release.png)
+4. Then we create the new tag v4.2.0, the important thing here is that we have to prefix the tag with the v, because this is the common practice.
+5. Then we select the previous version and automatically generate the release notes, ![alt text](doc/screenshots/release-readme/release-notes.png)
+6. Then we click _Publish Release_ ![alt text](doc/screenshots/release-readme/publish-release.png)
+
+Then we noticed that the pipeline was running again and it should deploy to the Maven central repository. It takes a while for the Maven repository to become publicly available.
+
+To check if the public repository in Maven already has the new version, we can go to https://central.sonatype.com/ and search for org.damap and see what version is published there.
+
+
+## Frontend Releases
+For the frontend is the same as for the backend.
+1. We create a new branch release.
+2. We change the version in package.json using the same semantic versioning strategy.
+3. Run npm install.
+4. After that we should check that the package-lock.json has the new version. The commit should be named as the new version.
+5. Then we add to the commit the package.json, package-lock.json and push them.
+6. Create the new PR and merge it.
+   Note: For the frontend we do not need to do the SNAPSHOT strategy at the end.
+7. Then do the same for the backend to create the new release. Go to the releases label on github.
+8. Create a new release.
+9. Choose the commit for the release.
+10. Create a tag and generate release notes.
+11. Publish the release.  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+