# 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.