On 11/02/26 22:44, Jeremy Stanley wrote:
We do push signed Git tags and we
publish signed tarballs built from these tagged states, but our tarballs
incorporate content from Git metadata that is not present in the raw
working tree that's checked into the repository.
A non-exhaustive list includes:
* setting internal version data for the software based on the name of
the corresponding tag in Git
* generating AUTHORS files referred to in some licenses
* associating loose release notes with the correct versions based on
the subsequent Git tag after the Git commits that added them
* generating changelogs
* release process information fetched in Git notes objects
As this sort of information is already present in the Git repository in
one form or another, we intentionally avoid checking duplicate copies of
it into the working tree. Doing so is racy in some cases, or risks
getting out of sync, as we're machine-coordinating and orchestrating
asynchronous development between thousands of contributors, so a
"release" tag is essentially a snapshot in time to which we can refer to
a known state of the repository by a convenient shorthand version number.
Hi Jeremy,
all the additions found in the tarball are generated automatically I
assume. Why can't they be simply added to the Git repo while creating
the tag in a classic "Releasing version foo" commit? (A common pattern
in Debian's Git repositories because of the need to update d/changelog
when doing a new release.)
Yes, the info in these extra files is going to be outdated soon, but you
can always preface them with something like "list of authors as of v1.2.3".
Also, I understand that you have thousands of people contributing on the
codebase, but do they all have push-access to the repository? Can't the
person creating the tag announce that the new release is going to happen
on day so and so? (Or do you routinely tag commits that are not the last
on the development branch? That could be addressed by something like
creating a release branch with only one commit containing these
autogenerated files, merging the branch with the previous 1-commit
release branch, and then tagging the merge commit.)
What I really don't understand is: losing 1-to-1 correspondence with the
git tree creates so many issues; is keeping this distinction really a
net win for your project and projects with similar workflows?
Regards,
--
Gioele Barabucci
