Hi Jeremy,
On 12/02/26 18:27, Jeremy Stanley wrote:
On 2026-02-12 11:07:09 -0600 (-0600), Richard Laager wrote:
On 2026-02-12 08:58, Jeremy Stanley wrote:
The point being, we don't necessarily know who the authors are until
we tag the release, and accurately updating an AUTHORS file in the
branch would have to happen after the tag is applied which means the
updated file wouldn't be included in that release.
Instead of _only_ tagging a particular commit as v1.2.3, you could
branch off that commit, commit the AUTHORS file update (and anything
else), then tag that as v1.2.3.
Whether that's worthwhile in your case is up to your project.
That's essentially trying to avoid the race conditions inherent in
metadata duplication by constricting the volume of activity and number
of actors involved in approving changes for that new temporary branch to
a small enough set that manual coordination is less costly.
Is it really different from what you are already doing when you create
the tarball? Currently someone has to:
1. pick a commit,
2. tag it,
3. run a script to create the extra files,
4. put everything in a tarball,
5. sign it,
6. publish it.
In the Git-only version steps 4, 5 and 6 would become:
checkout -b v1.2.3-relase
git add .
git commit -m 'Release version 1.2.3'" --gpg-sign
git push
or:
checkout -b v1.2.3-relase
git add .
git commit -m 'Release version 1.2.3'"
git tag --sign v1.2.3-full
git push; git push --tags
The person doing the release would be the same, all constraints would be
the same. But now the Git repo would have all the info that is in the
tarball. (And the tarball could be generated via a simple `git archive
v1.2.3-full`, with the extra assurance that it matches what is in Git.)
Regards,
--
Gioele Barabucci
