File: dev_releases.md

package info (click to toggle)
commitizen 4.10.1-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 2,892 kB
  • sloc: python: 17,728; makefile: 15
file content (73 lines) | stat: -rw-r--r-- 1,965 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
# Dev Releases

## About

To make use of a `.dev` suffix, as per
[PEP440](https://peps.python.org/pep-0440/#developmental-releases).

If multiple active branches attempt to create a tag relative to the main branch, there is a possibility that they will attempt to create the _same_ tag, resulting in a collision.

Developmental releases aim to avoid this by including a `.dev` segment which
includes a non-negative integer unique to that workflow:

```txt
X.Y.devN
```

!!! note
    As noted in
    [PEP440](https://peps.python.org/pep-0440/#developmental-releases),
    while developmental releases help avoid the situation described above, they can be _"difficult to parse for human readers"_ depending on the value passed as the developmental release.

## How to

### Example 1: CircleCI

For example, CircleCI [provides](https://circleci.com/docs/variables/)
`CIRCLE_BUILD_NUM`, a unique number for each job which will increment with each
run:

```sh
--devrelease ${CIRCLE_BUILD_NUM}
```

This will result in a unique developmental release of, for example:

```sh
1.3.2.dev2478
```

### Example 2: GitHub

GitHub also
[provides](https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables)
`GITHUB_RUN_ID`, a _"unique number for each workflow run"_ which will also
provide a unique number for each workflow:

```sh
--devrelease ${GITHUB_RUN_ID}
```

This will result in a unique developmental release of, for example:

```sh
1.3.2.dev6048584598
```

### Example 3: Unix time

Equally, as the developmental release needs only a non-negative integer, it is
possible to use the Unix time (i.e. the number of seconds since 1st January
1970 UTC).

This approach could potentially create a collision if two builds occur at precisely the same second, but it may be sufficient for many use cases:

```sh
--devrelease $(date +%s)
```

This will result in a unique developmental release of, for example:

```sh
1.3.2.dev1696238452
```