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. I agree it's an option, but at least in our case the increase in both complexity and human engagement would need to be sufficiently offset by downstream convenience to make it worthwhile.
The workflows we're following and automation we're using were initially designed at a time when most distributions, Debian among them, preferred release tarballs over upstream revision control, to the point where the practice of package maintainers creating new "upstream" tarballs from Git and ignoring official release tarballs was strongly discouraged rather than encouraged. We focused on making our release tarballs comprehensive for the benefit of those distributions even though our source code was maintained upstream in Git, and did not foresee a future where those distros would want to use the working trees from our repositories but not keep the associated repository metadata.
Things change, and it's not clear to me whether there's benefit in jumping though hoops to duplicate metadata into the working tree, if downstream workflows are just as likely to shift again.
-- Jeremy Stanley
signature.asc
Description: PGP signature
