-
-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TOTHINK: In git snapshot rebuilds, suffix NUT version with number of commits since release #1949
Comments
Autorevision is made for doing exactly this and there are even examples using make. |
Looks neat, thanks! |
Looking around, I saw we have precedent of a similar approach in configuration of nut-website at https://github.com/networkupstools/nut-website/blob/64361632b90ed427b5bc2e364e37ccdc8118ffe6/configure.ac#L5 Granted, changes or mishaps there are less intrusive (no end-users or tarballs to get wrong) in case of mistakes. |
This comment was marked as duplicate.
This comment was marked as duplicate.
Variant of the above updates, with debugging and restored tail of the
Checked with Some experiments (output line-wrapped):
So this hack seems to best marry the two worlds for NUT purposes. Note that the local git repo index must know of the fresh trunk history which is not always a given (see #2551) to properly generate such information. Also note that use of annotated git tags in maintenance is crucial for this feature by default, as they are the ones intended for releases (or extra
In an extreme case of a different project's repo with no annotated tags, just the hash is returned:
Interesting report from a system whose knowledge of
|
Signed-off-by: Jim Klimov <[email protected]>
…uctured version from Git (if available) [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…version.sh for version info [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
Signed-off-by: Jim Klimov <[email protected]>
For autotools integration, got interesting inspiration from discussion at https://lists.gnu.org/archive/html/bug-autoconf/2024-01/msg00022.html to have the information generated into an m4 file (whether by |
…and URL, and IS_RELEASE [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…R_GIT toggle [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…INIT without hacks [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…leases [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…AULT file [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…stools#1949] Signed-off-by: Jim Klimov <[email protected]>
…iendly versioning scheme [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…ort [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…ITREV_SEMVER [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…CRO and NUT_VERSION_IS_RELEASE [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…in the loop [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…upstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…f present [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…VERSION_FORCED_SEMVER` files in our release rituals, we have support anyway and want to test it in-vivo [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…tworkupstools#1949] Merge branch 'issue-1949-url' as PR networkupstools#2563 Signed-off-by: Jim Klimov <[email protected]>
…networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…tps://www.networkupstools.org/" if PACKAGE_URL points completely elsewhere) [networkupstools#1949] Tested with "VER" command Signed-off-by: Jim Klimov <[email protected]>
…ed "https://www.networkupstools.org/" if PACKAGE_URL points completely elsewhere) [networkupstools#1949] Tested with "GET VAR dummy server.info" command Signed-off-by: Jim Klimov <[email protected]>
…AYS_DESC toggle envvar [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…fully (and abort if there is no common BASE) [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…tps://www.networkupstools.org/" if PACKAGE_URL points completely elsewhere) [networkupstools#1949] Tested with "VER" command Signed-off-by: Jim Klimov <[email protected]>
…ed "https://www.networkupstools.org/" if PACKAGE_URL points completely elsewhere) [networkupstools#1949] Tested with "GET VAR dummy server.info" command Signed-off-by: Jim Klimov <[email protected]>
…AYS_DESC toggle envvar [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…fully (and abort if there is no common BASE) [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…ailed and we fall back [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…tps://www.networkupstools.org/" if PACKAGE_URL points completely elsewhere) [networkupstools#1949] Tested with "VER" command Signed-off-by: Jim Klimov <[email protected]>
…ed "https://www.networkupstools.org/" if PACKAGE_URL points completely elsewhere) [networkupstools#1949] Tested with "GET VAR dummy server.info" command Signed-off-by: Jim Klimov <[email protected]>
…AYS_DESC toggle envvar [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…fully (and abort if there is no common BASE) [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…ailed and we fall back [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…ver DESC or BASE data [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…lt version info data point [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…lt version info data point [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…_GIT_TRUNK if not provided explicitly [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…es, and add master in the end too [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
…es, and add master in the end too [networkupstools#1949] Signed-off-by: Jim Klimov <[email protected]>
Signed-off-by: Jim Klimov <[email protected]>
Autoconf tricks to allow embedding the git version are explored in autoconf's own build scripts:
A practical implementation example (not with git version, but still - with a command) can be seen at https://github.com/exfatprogs/exfatprogs/blob/master/configure.ac#L3-L11 or MidnightCommander/mc@eab8439 with a fully-fledged script.
The idea here might be to determine a release tag (annotated? by pattern?) as opposed to major milestones, release candidates etc. tagged during development), and count the number of commits since then.
A release might be tagged
v2.8.0
(disregarding items likev2.8.0-Windows
,Windows-v2.8.0-alpha4
orv2.8.1-rc1
which might have happened later, but maybe including patterns likev2.8.0-signed
(which should refer to same commit as originalv2.8.0
but with a signed tag object) and then the custom build would be configured asAC_INIT([nut], [2.8.0.123]...)
for 123 commits after that release.If this tweak to metadata works, it would be more idiomatic (and welcoming to rolling-release packaging form master branch by CI, for example) than calling all such custom builds formally
2.8.0.1
and detailing the git maturity level in plain comments or help messages which are not easily machine-parsable.For bonus points, we may want to track the codebase maturity compared to both master and last release, perhaps
2.8.0.123.45
meaning that "master" branch had 123 commits since last release (2.8.0) and then the currently branched-off effort for a PR added 45 commits on top of that newest commit in the PR branch that is also in known master branch history (the branching or last-resync point), or alternately - just say 345 commits tracked in the PR branch overall when also counting since that release, which may be easier to tackle.Then a build from newer master branch with 130 commits (or of a PR with foundations on that baseline) would win in terms of automated packaging version resolution, etc. despite the longer (and variable) amount of commits in development branches.
By either count, a release (tag, tarball) would then be pedantically (equivalent to)
2.8.1.0
or2.8.1.0.0
; for most packaging systems trailing zeroes may be ignored so2.8.1
as usual.UPDATE from Jul 2024: In current
configure.ac
we trackAC_INIT
with a fixed version string (e.g.2.8.2
committed manually when making a release, and2.8.2.1
persisting for development versions), and separately defineNUT_SOURCE_GITREV
via shell script parsing of tailoredgit describe
output. This is further stripped intoNUT_SOURCE_GITREV_NUMERIC
substituted into e.g. PyPI packaging manifest:Elaborating on the idea of tracking two version increments on top of a formal release - of trunk (master) since last release and of current code since trunk, so that snapshot package versions are incremental and easy to upgrade:
mc
recipe linked above,--abbrev=0
can be used to strip the commit count and current hash, leaving just the nearest git tag name.configure.ac
we add a lot of arguments to strip non-release tags from consideration.FTY
branch has so far thousands of DMF and other commits that are not part ofmaster
-branch history. Even though it is lately regularly merged-into frommaster
, there are many commits seen as unique to it (thanks to backports per Upstreaming improvements from 42ity/nut fork #1316 many of these bring no diff's in content, just metadata). So the current state in one PR branch is NUT releasev2.8.2
as baseline (the TAG), with currentmaster
adding 695 commits on top of that, and the branch having 3200 commits different from master:2.8.2
but2.8.2.695
just because newermaster
history is knownand reference is hard-coded in the example line. But this example shows that the possibilities are there. Just need to compare history lengths leading to HEAD via branch-off from master (which would be 0 in case of older tag).git log --ancestry-path a..b
UPDATE2: Looking at "git merge-base" of current HEAD and known
master
trunk history, as the branch-off point (or just an older tag or other commit present in trunk) yields reasonable results:Primary question would rather be how to reconcile any such value derived from git with static offline-only files available in tarballs (return to some
version.txt
?); perhaps have a default-version file with e.g.2.8.2.1
as used inAC_INIT
now, tracked in SCM (and tarballs by extension) and updated fromautogen.sh
orconfigure.ac
only ifgit
is usable. Note that building or developing based on code from tarballs without git, and re-generating withautogen.sh
along the way, is a valid scenario.CC @clepple @aquette : WDYT?
The text was updated successfully, but these errors were encountered: