technofab/bumpver
1
0
Fork 0
mirror of https://github.com/TECHNOFAB11/bumpver.git synced 2025-12-12 14:30:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

more readme updates

Browse source
This commit is contained in:
Manuel Barkhau 2018-12-22 00:51:46 +01:00
parent d4a72a2236
commit 220ee07976
1 changed files with 34 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

53
README.md
View file

@ -496,7 +496,7 @@ README.md =
Notice that neither the "v" prefix, nor the "." and "-" Notice that neither the "v" prefix, nor the "." and "-"
separators are included in the pattern text, as they are separators are included in the pattern text, as they are
respectivly part of the `calver`, `build` and `release` respectively part of the `calver`, `build` and `release`
placeholders. Alternatively you can be more explicit. placeholders. Alternatively you can be more explicit.
```ini ```ini
@ -519,11 +519,12 @@ The current version that will be bumped is defined either as
- Typically: The lexically largest git/mercurial tag in the - Typically: The lexically largest git/mercurial tag in the
repository. repository.
As part of doing `pycalver bump`, your local VCS index is As part of doing `pycalver bump`, your local VCS index is updated
updated using `git fetch --tags`/`hg pull`, to ensure that all using `git fetch --tags`/`hg pull`. This ensures that all tags
tags are known locally and the same version is not generated for are known locally and the same version is not generated for
different commits. This is mitigates a rare corner case where different commits, and mitigates the risk of a rare corner case,
`pycalver bump` is invoked on different machines. where `p`pycalver bump` is invoked on different machines. If you're
the only maintainer, you can always use `-n/--no-fetch`.
```shell ```shell
@ -547,6 +548,7 @@ To increment and publish a new version, you can use the
5. *Tag* the new commit. 5. *Tag* the new commit.
6. *Push* the new commit and tag. 6. *Push* the new commit and tag.
Again, you can inspect the changes first.
``` ```
$ pycalver bump --dry $ pycalver bump --dry
@ -563,23 +565,35 @@ $ pycalver bump --dry
... ...
``` ```
If everything looks OK, you can do `pycalver bump`.
```
$ pycalver bump --verbose
INFO - fetching tags from remote (to turn off use: -n / --no-fetch)
INFO - Old Version: v201812.0005-beta
INFO - New Version: v201812.0006-beta
INFO - git commit --file /tmp/tmpph_npey9
INFO - git tag --annotate v201812.0006-beta --message v201812.0006-beta
INFO - git push origin v201812.0006-beta
```
### Version State ### Version State
The "current version" is considered global state that needs to The "current version" is considered global state that needs to be
be stored somewhere. Typically this might be stored in a stored somewhere. Typically this might be stored in a `VERSION`
`VERSION` file, or some other file which is part of the file, or some other file which is part of the repository. This
repository. This creates the possibility that different parallel creates the risk that parallel branches can have different
branches can have different states, which might lead to the same states. If the "current version" were defined only by files in
version number being generated for different commits. the local checkout, the same version might be generated for
different commits.
To avoid this issue, pycalver treats VCS tags as the canonical / To avoid this issue, pycalver treats VCS tags as the canonical /
(SSOT)[https://en.wikipedia.org/wiki/Single_source_of_truth] for [SSOT][ssot_ref] for the most recent version and attempts to
the most recent version and attempts to change this state in the change this state in the most atomic way possible. This is why
most atomic way possible. This is why some actions of the some actions of the `pycalver` command can take a while, as it is
`pycalver` command can take a while, as it is synchronizing with synchronizing with the remote repository to get the most recent
the remote repository to get the most recent versions and to versions and to push any new version tags as soon as possible.
push any new version tags as soon as possible.
### Lexical Ids ### Lexical Ids
@ -645,12 +659,13 @@ have no logic to parse version strings, which can nonetheless
order the version tags correctly. order the version tags correctly.
## References
[repo_ref]: https://gitlab.com/mbarkhau/pycalver [repo_ref]: https://gitlab.com/mbarkhau/pycalver
[setuptools_ref]: https://setuptools.readthedocs.io/en/latest/setuptools.html#specifying-your-project-s-version [setuptools_ref]: https://setuptools.readthedocs.io/en/latest/setuptools.html#specifying-your-project-s-version
[ssot_ref]: https://en.wikipedia.org/wiki/Single_source_of_truth
[pep_440_ref]: https://www.python.org/dev/peps/pep-0440/ [pep_440_ref]: https://www.python.org/dev/peps/pep-0440/
[zeno_1_dot_0_ref]: http://sedimental.org/designing_a_version.html#semver-and-release-blockage [zeno_1_dot_0_ref]: http://sedimental.org/designing_a_version.html#semver-and-release-blockage