Skip to content

Commit

Permalink
Update developer_documentation.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@meier-rene
meier-rene authored Sep 1, 2023
1 parent 10abd43 commit 3d76250
Showing 1 changed file with 7 additions and 10 deletions.
17 changes: 7 additions & 10 deletions developer_documentation.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -176,35 +176,32 @@ $ hub release create 2.1
The release strategy of MassBank-data is similar to the one of MassBank-web and is described below. Additionally it needs to be taken care of the validation and the codebase for the validation.

## Main branches
We use two main branches, `main` and `dev`. All development should happen in `dev` and we define every commit to `main` to be a release. When new data in the `dev` branch has reached a stable point and is ready to be released, all of the changes should be merged back into `main` somehow and then tagged with a release number. The data of `main` should be validated with the `main` of MassBank-web and the data of `dev` should be validated with `dev` of MassBank-web. If the data contains incompatible changes MassBank-web needs to be released first, because before a merge to `main` is possible a validation needs to be successfully. The code base for the validation is defined in travis.yml. Depending on the given version the `bump-version.sh` script adjusts the content of travis.yml to choose the corresponding branch from MassBank-web. If the version tag contains `SNAPSHOT` like in `2019.09-SNAPSHOT` its identified as `dev` data branch and travis will pull the `dev` branch of MassBank-web for validation. If `SNAPSHOT` is missing its identified to be a release version and travis will pull the `main` branch of MassBank-web for validation. All versions which get a release tag in github are used by a webhook from zenodo and get a DOI attached. The authors list of the record at zenodo needs to be manually edited to contain `MassBank-consortium and its contributors`.

The release process is discussed in detail below. To use all of the command lines below the [github/hub](https://github.com/github/hub) tool is required.
We use two main branches, `main` and `dev`. All development should happen in `dev` and we define every commit to `main` to be a release. When new data in the `dev` branch has reached a stable point and is ready to be released, all of the changes should be merged into `main` and then tagged with a release number. The data of `main` should be validated with the `main` of MassBank-web and the data of `dev` should be validated with `dev` of MassBank-web. If the data contains incompatible changes MassBank-web needs to be released first, because before a merge to `main` is possible a validation needs to be successfully. All versions which get a release tag in github are used by a webhook from zenodo and get a DOI attached. The authors list of the record at zenodo needs to be manually edited to contain `MassBank-consortium and its contributors`.

The release process is discussed in detail below. To use all of the command lines below the [github/hub](https://hub.github.com/) tool is required.

### Release branches
Release branches are created in preparation of a release.

Branch off from: `dev`

Must merge back into: `main`

Branch naming: `release-*`

Release branches support preparation of a new production release. They allow for preparing the version number for a release.
Release branches support preparation of a new release. They allow for preparing the version number for a release.

#### Creating a release branch
```
$ git checkout -b release-2019.09 dev
Switched to a new branch "release-2019.09"
$ ./bump-version.sh 2019.09
Set version of release to 2019.09. This version will validate against the main branch of MassBank-web.
git add .travis.yml VERSION
git commit -m "Bumped version number to 2019.09"
$ git add VERSION
$ git commit -m "Bumped version number to 2019.09"
[release-2019.09 74d9424] Bumped version number to 2019.09
$ git push --set-upstream origin release-2019.09
```

#### Finishing a release branch
When the state of the release branch is ready to become a real release, the release branch is merged into `main` with a pull request and tagged for easy future reference.
When the state of the release branch is ready to become a real release, the release branch is merged into `main` with a pull request and tagged/released for easy future reference.

```
$ hub pull-request -m 'Release version 2019.09' -b main
Expand Down

0 comments on commit 3d76250

Please sign in to comment.