dash/contrib/containers/guix
UdjinM6 f72650d2de
feat: Set client version for non-release binaries and version in guix based on git tags (#5653)
## Issue being fixed or feature implemented
Client version string is inconsistent. Building `v20.0.0-beta.8` tag
locally produces binaries that report `v20.0.0-beta.8` version but
binaries built in guix would report
`v20.0.0rc1-g3e732a952226a20505f907e4fd9b3fdbb14ea5ee` instead. Building
any commit after `v20.0.0-beta.8` locally would result in versions like
`v20.0.0rc1-8c94153d2497` which is close but it's still yet another
format. And both versions with `rc1` in their names are confusing cause
you'd expect them to mention `beta.8` instead maybe (or is it just me?
:D ).

## What was done?
Change it so that the version string would look like this:
on tag: ~`v20.0.0-beta.8-dev` or `v20.0.0-beta.8-gitarc`~
`v20.0.0-beta.8`
post-tag: ~`v20.0.0-beta.8-1-gb837e08164-gitarc`~
`v20.0.0-beta.8-1-gb837e08164`

post-tag format is
`recent tag`-`commits since that tag`-`g+12 chars of commit hash`-`dirty
(optional)` ~-`dev or gitarc`~

~`dev`/`gitarc` suffixes should help avoiding confusion with the release
versions and they also indicate the way non-release binaries were
built.~

Note that release binaries do not use any of this, they still use
`PACKAGE_VERSION` from `configure` like before.

Also, `CLIENT_VERSION_RC` is no longer used in this setup so it was
removed.

Few things aren't clear to me yet:
1. Version bump in `configure.ac` no longer affects the reported version
(unless it's an actual release). Are there any downsides I might be
missing?
2. Which tag should we use on `develop` once we bump version in
configure? `v21.0.0-init`? `v21.0.0-alpha1`?
3. How is it going to behave once `merge master back into develop` kind
of PR is merged? E.g. say `develop` branch is on `v21.0.0-alpha1` tag
and we merge v20.1.0 from `master` back into it. Will this bring
`v20.1.0` release tag into `develop`? Will it become the one that will
be used from that moment? If so we will probably need another tag on
`develop` every time such PR is merged e.g. `v21.0.0-alpha2` (or
whatever the next number is).

Don't think these are blockers but would like to hear thoughts from
others.

## How Has This Been Tested?
Built binaries locally, built them using guix at a specific tag and at
some commit on top of it.

## Breaking Changes
n/a

## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
2024-01-11 21:43:42 -06:00
..
scripts feat: Set client version for non-release binaries and version in guix based on git tags (#5653) 2024-01-11 21:43:42 -06:00
docker-compose.yml contrib: move context to repository root, use additional context for copy 2023-06-27 20:24:08 +05:30
Dockerfile ci: Bump Guix build timeout and implement cacheing (#5727) 2023-12-01 09:11:35 -06:00
motd.txt contrib: create Guix container with interactive abilities 2023-06-27 20:24:08 +05:30