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
47 lines
1.8 KiB
Markdown
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. |