... | ... | @@ -164,5 +164,21 @@ Once there is nothing more to do in release candidates, you can deploy the final |
|
|
|
|
|
## 6. Nabu release policy
|
|
|
|
|
|
pl
|
|
|
### 6.1 - Version numbers
|
|
|
|
|
|
Nabu uses [Calendar versioning](https://calver.org). This means that versions are in the form `20XX.Y.Z`, for example `2020.3.0` for third major release of 2020.
|
|
|
|
|
|
### 6.2 - Major and minor releases
|
|
|
|
|
|
Calendar versioning does not define a direct equivalent of "major" and "minor" versions from semantic versining.
|
|
|
In our case, the scheme "version `20XX.Y.Z` is the following:
|
|
|
- Year: `20XX`
|
|
|
- Major release: `Y` (one-based)
|
|
|
- Revision: `Z` (zero-based)
|
|
|
|
|
|
For example: version `2020.1.0` is the first major release (without revision) in 2020 ; version `2020.2.1` is the first revision of second major release of 2020.
|
|
|
|
|
|
### 6.3 - Release schedule
|
|
|
|
|
|
The DAU project [silx](https://www.silx.org) uses a "fixed release rate" (every 3 or 6 months).
|
|
|
Nabu releases are done according to a [roadmap](https://tomotools.gitlab-pages.esrf.fr/tomo-bridge-docs/data-proc/roadmap), which can include intermediate releases. Therefore, there is no "fixed release rate", although we tend to make at least one major release every 3 months. |