[quote=“Patrick, post:7, topic:360”]I would like to implement a few more features.
Please check if the parameter names and descriptions make sense.
make tag-sign
Sign git tag of latest debian/changelog version.
make tag-push
Push git tag of latest debian/changelog version.
make tag-verify
Verify git tag of latest debian/changelog version.
make tag-verify-checkout
Verify and checkout git tag of latest debian/changelog version.
make tag-check
Check if current git head needs to be tagged.
“make tag-sign” - should be easy to implement. (git tag -s “${make_pkg_version}-${make_pkg_revision}” -m . + sanity tests)
[hr]
“make tag-verify” - should be easy to implement. (git tag -v “${make_pkg_version}-${make_pkg_revision}” + sanity tests)
[hr]
“make tag-verify-checkout” - should be easy to implement. (git tag -v “${make_pkg_version}-${make_pkg_revision}” + git checkout “${make_pkg_version}-${make_pkg_revision}” + sanity tests)
[hr]
“make tag-push” - Not sure how to implement this. I would prefer something like “make tag-push origin adre”, where “origin” and “adre” are git remotes. (“git push adre gittag”). “origin” and “adre” a variables. Different devs have different git remote names. Unfortunately, make files don’t have a pretty way to pass command line parameters:
And “make tag-push REPO=origin” looks a bit ugly. Any ideas?[/quote]
Use a configuration file that the Makefile imports
Makefile
WHONIXCONF ?= whonix.conf
#Include config file
-include $(WHONIXCONF)
Then you can include any variables you will need in the config file. The config is really a Makefile format.
whonix.conf
REPO = origin
BUILD_TYPE = gateway
64BIT_LINUX = 1
CURRENT_SOURCES = 1
ENABLE_WHONIX_APT_REPOSITORY = 1
WHONIX_APT_REPOSITORY_DISTRIBUTION = wheezy
INSTALL_TO_ROOT = 1
SKIP_VERIFIABLE = 0
MINIMAL_REPORT = 0
SKIP_SANITY_TESTS = 0
Now you can over-ride the default config file by setting an environment variable or calling make like this:
WHONIXCONF=other.conf make <option>
"make tag-check" - The problem I want to solve here...
When there is a good time for tagging a git tag and/or bumping [debian/changelog] version numbers is non-obvious to me. Let’s say for example current git head is a8faad584571620ba42d26eb95069aac96e54379, current debian/changelog version is 0.7-1, tagged as 0.7-1. Now, when development continues and I am adding new commits, should I when the next commit is added on top of 0.7-1 already bump the [debian/changelog] version number? And when I think that version is ready, finalize it by git tagging it?
I’d like to prevent confusion and non-consistent results here. Someone who fetches the git repo’s master, using git head that might be a few commits ahead of 0.7-1, who runs “make deb-pkg” or even “make deb-icup” might think 0.7.1 is being installed, while (git describe output:) 0.7-1-2-geb9ac5f is being used.
“make tag-check” would run “git describe” and check if it’s output matched the debian/control version number. Exit 0 if it matches, error and exit 1 otherwise. Before a mass git tagging of all packages or mass git tag pushing, I could run a mass “make tag-check” to see if I still need to finalize/git tag releases. What do you think?
Input appreciated.
Personally, I think everything in master should be tagged.
So to start the tags is 0.7-1, you keep working adding commits and tag those as xx_1234abdfdsfsdd, where ‘xx’ is your initials and ‘1234abdfdsfsdd’ is the current HEAD. Now when you are ready to up the version, you then tag it as 0.7-2.
This makes it clear
