Re: How do i get news of git releases

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 22, 2025, 21:16 UTC
Message-ID: <xmqqtt0urxva.fsf@gitster.g>
In-Reply-To: <20250922203815.GA2264272@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Yes, they're already annotated tags. But they contain only the version
> number and signature. I suppose they could include the whole set of
> release notes (and it looks like we used to do that in some very old
> tags),

Eh, which one? I do not recall ever doing so, but I may be mistaken.

"git show v0.99.1" gives both tag object contents *and* the output from "git show v0.99.1^0" for the commit, so it is possible that I never did so, but those who ask "git show" may get such an impression?

Show 20 quoted lines

> but there may be some possible downsides:
>
>   1. I'm not sure if anybody depends on the current format for
>      scripting.
>
>   2. They can't be revised if we later fix up the Release Notes (e.g.,
>      typo fixes, but also they were recently all retroactively brushed
>      up to be renderable as asciidoc).
>
>   3. The resulting objects would be much larger (the v2.51.0 tag is 974
>      bytes, but Documentation/RelNotes/2.51.0 is 14K, and some are even
>      larger). Git may open them frequently to peel the tags, which may
>      make some operations slower. Though it might be OK; we try to cache
>      peeled values in packed-refs, and possibly the peeling code could
>      learn to parse more progressively (e.g., grab the first 1K to see
>      if we hit the end-of-header there).
>
> Those aren't necessarily show-stoppers, but just some top-of-the-head
> thoughts. Junio (the maintainer, who actually makes the tags) might have
> more thoughts on why we used to do that sometimes and don't now.

I think #3 is a show-stopper.

We will keep the RelNotes file updated with every batch that updates the 'master' front, so the contents of that imaginary tag that has the copy of the release notes would become identical to the in-tree blob at the point of a release. There has to be a very good reason why it is beneficial to _duplicate_ the information, not the other way around to ask why we do not duplicate the information in different places, I think.