|
|
This page describes how versions or code (applications, libraries....) are handled in relation with tags in GitLab by using the bump2version tool. |
|
|
\ No newline at end of file |
|
|
This page describes how versions or code artefacet (applications, libraries....) are handled in relation with tags in GitLab by using the bump2version tool.
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
|
# Concepts
|
|
|
|
|
|
Every release of the code is identified with a tag in the GitLab repository.
|
|
|
|
|
|
We want that executables/applications, scripts, utilities, user interfaces and other artefacts are assigned a version identifier based on the release tag and that this can be queried.
|
|
|
|
|
|
In order to make this process as much a possible automatised and uniform across projects we describe here a workflow and conventions based on the usage of the bump2version tool.
|
|
|
|
|
|
The basic principles are:
|
|
|
- Conventional strings are used to identify a version
|
|
|
- These strings
|
|
|
- are used in the code in the various languages by functions that print out the version of a tool, for example with the `--version` command line option
|
|
|
- or can be simply grepped or extracted from files or binaries to verify the version or an ertefact
|
|
|
|
|
|
# `bump2version`
|
|
|
|
|
|
`bump2version` (or just `bumpversion`, the terms are synonims) is small command line tool written in python to simplify releasing software by updating all version strings in your source code by the correct increment.
|
|
|
|
|
|
Also creates commits and tags
|
|
|
|
|
|
The web page with documentation is here: https://github.com/c4urself/bump2version
|
|
|
|
|
|
Waf and ELT DevEnv provide some support, and more will be probably added in the future.
|
|
|
|
|
|
# `.bumpversion.cfg`
|
|
|
|
|
|
- The `.bumpversion.cfg` file contains the configuration for the `bumpversion` command
|
|
|
- This file shall appear in the the root folder of a project
|
|
|
- *Note:* The file is automatically overwritten every time the `bumpversion` command is executed. Therefore, do not change it by hand and do not put there comments, as they will be removed at the next ececution.
|
|
|
|
|
|
What follows is an example of `.bumpversion.cfg` file, with additional comments:
|
|
|
|
|
|
```
|
|
|
[bumpversion]
|
|
|
current_version = 0.1.0-pre1
|
|
|
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)([-](?P<release>(pre|rc))(?P<build>\d+))?
|
|
|
serialize =
|
|
|
{major}.{minor}.{patch}-{release}{build}
|
|
|
{major}.{minor}.{patch}
|
|
|
|
|
|
commit = True
|
|
|
sign_tags = False
|
|
|
tag_message = Release v{new_version}
|
|
|
message = Bump v{current_version} -> v{new_version}
|
|
|
|
|
|
[bumpversion:part:release]
|
|
|
first_value = pre
|
|
|
optional_value = ga
|
|
|
values =
|
|
|
pre
|
|
|
rc
|
|
|
ga
|
|
|
|
|
|
[bumpversion:part:build]
|
|
|
first_value = 1
|
|
|
|
|
|
[bumpversion:file:.version]
|
|
|
|
|
|
[bumpversion:file:wscript]
|
|
|
search = "{current_version}"
|
|
|
replace = "{new_version}"
|
|
|
|
|
|
[bumpversion:file:telsimui/src/hlcc/telsimui/__init__.py]
|
|
|
search = "{current_version}"
|
|
|
replace = "{new_version}"
|
|
|
|
|
|
[bumpversion:file:doxy.conf]
|
|
|
search = PROJECT_NUMBER={current_version}
|
|
|
replace = PROJECT_NUMBER={new_version}
|
|
|
|
|
|
|
|
|
``` |
|
|
\ No newline at end of file |