# Release to debian repositories

## Script
You can run `node ./release.js [M.m.p]`

`M.m.p` for the Major, minor and patch version respectively.
If not provided, a new build of the current version will be released.

You can also run with `--patch`, `--minor`, `--major` arguments to bump & release the current version respectively in patch, minor, major version.

Or you can run things manually if you want to customize the process.
The script basically executes the commands below:

## Manual

Before releasing/tagging purple, make sure that the package.json file on the rc branch reflects the version you want to release.
If necessary, adjust the version field in the package.json before proceeding with the release process.

Our current `rc` branch is targetted at debian 10 (`buster` or `brie` in barco terms).
Our `giles/rc` branch is targetting debian 9 (`stretch` or `giles` in barco terms).
The current barco main branch (`vclub`) is debian 10 as well. (`brie` being a derivative from `vclub`).

You need to keep all debian branches up to date.

First create a build of purple for the current RC (currently debian 10 / `brie`).
Substitute the numbers in this example (`M.m.p` for the Major, minor and patch version respectively and `N` for the number of the build, starting with 1 and increasing at every new build which doesn't have an updated purple version).
````sh
# in this example, releasing for brie (which has major version 10)
git checkout rc
git pull
git tag M.m.p@barco10+N
git branch -f production/brie M.m.p@barco10+N
git push --tags origin production/brie
````

The tag is basically: `[major].[minor].[patch]@barco[debian version]+[build number]`
Debian version is only the major version (9 for stretch/giles, 10 for buster/vclub/brie).

In order for a tagged release to get published inside a given debian version, the major version number in the tag must match the version number of that debian release.
This means that you should only point `production/brie` to a `M.m.p@barco10+N` tag, and `production/giles` should only ever point to a `M.m.p@barco9+N` tag.
This would mean that you might want to "publish" the same purple version multiple times (for multiple debian versions). 
Unfortunately, the build pipeline does not allow having multiple tags on the same commit.
To work around this, you must create a new, empty commit for every additional tag.
This means that, for every extra(/older) debian version, you should run the following:
```sh
# in this example, releasing for giles (which has major version 9)
git checkout giles/rc
git rebase rc
git commit --allow-empty -m "chore: release M.m.p@barco9+N"
git push -f
git tag M.m.p@barco9+N
git branch -f production/giles M.m.p@barco9+N
git push --tags origin production/giles
```

### Vclub is always the current barco branch which also needs to be kept up to date.
Assume you are on the `vclub/rc` branch and a tag M.m.p@barco10+N has been set on `rc` and we want to release this on `vclub`
Note that @ means 'before' hence barco10+(N+1)@vclub1 means 'before barco10+(N+1) and for the vclub repo' (recommended way of working by SLIM)
```sh
git branch -f production/vclub M.m.p@barco10+N
git push --tags -f origin production/vclub
git checkout production/vclub
git commit --allow-empty -m "chore: release M.m.p@barco10+(N+1)@vclub1"
git push
git tag M.m.p@barco10+(N+1)@vclub1
git push --tags
```