Files
Masterarbeit/QuellCode/CentronERP/docs/operations/release-stop.md
T
Christoph Schwörer f045b99a25 Codebasis als Dateien ins Arbeitsrepo statt als Gitlink
QuellCode/CentronERP war nur als Gitlink (Submodul-Referenz auf 79c1142)
getrackt, ohne .gitmodules und ohne erreichbares Remote. Der
Untersuchungsgegenstand der Versuchsreihe war damit nicht reproduzierbar
gesichert: Ein Klon haette ein leeres Verzeichnis erhalten, und die Belege
der 3.287 Anforderungen waeren nicht ueberpruefbar gewesen.

Umstellung:
- Historie nach c:\DEV\CentronERP_git_snapshot_79c1142 ausgelagert
  (vollstaendig lesbar, enthaelt 79c1142 und Vorgaenger 89ccfd6)
- Gitlink aus dem Index entfernt
- Dateiinhalt aufgenommen: 24.557 Dateien, rund 333 MB

Die verschachtelte .gitignore der Codebasis gilt weiter, Build-Artefakte
bleiben ausgeschlossen. Details in Versuche/Versuch_01/_Codebasis-Nachweis.md
2026-08-26 07:43:51 +02:00

47 lines
1.8 KiB
Markdown

# How to release stop
## Bump the version.txt
Creating a release stop is pretty simple.
First, you have to bump the version number in the **version.txt** file.
For example, it's **currently at 2.0.1908**, and we would like to have a **release stop** for this **2.0.1908** release.
So what you do is you go ahead and **change it to 2.0.1909**.
Of course still use the usual workflow of separate branch, pull request, and merge.
After the change is merged into the `master` branch, every next version created, will have a **2.0.1909** version number.
## Create the release branch
Now you go ahead and **create a `release` branch based on the commit before the version bump.**
For example, the `master` branch after merging the version bump looks like this:
```
* <- Merged PR ABC: Version Bump [Current state of master, will create build 2.0.1909.2]
|\
| \
| * <- Version Bump to 2.0.1909 in the pull request branch [Commit in the PR]
| /
|/
* <- Merged PR XYZ: Some other thing [Commit before the version bump]
|\
| \
other commits...
```
Create a new branch named `release/v2.0.1908` based on `Merged PR XYZ: Some other thing`.
Push this branch to the Azure DevOps server, and then we have to configure some **branch policies**.
## Branch policies
The branch policies are setup automatically for all branches starting with `release/`, so there is nothing you have to do for the branch policies.
It is already taken care of.
## Automatic downloader
Now that the new version **2.0.1909** will be created, consider adding it to the **automatic downloader**.
This will allow everyone working at NEXOWARE to more easily get the latest builds of that version.
How to do that, and many more information on the automatic downloader are available in the [our build server and automated builds](./Our-build-server-and-automated-builds.md#automatic-downloader) page.