Re: GNU Binutils 2.41 release

[Tsukasa OI <li@livegrid.org>]

On 2023/08/01 18:43, Nick Clifton via Binutils wrote:
> Hi H.J.
> 
>> The binutils-2_41 tag points to the wrong commit:
>>
>> d3cc73ee4a (HEAD -> binutils-2_41-branch, origin/binutils-2_41-branch)
>> Updated Spanish translation for the gprof directory
>> ae85bd64903 Automatic date update in version.in
>> 7872e3bdb0d Reset 2.41 branch back to development mode
>> 2c73aeb8d2e (tag: binutils-2_41) The 2.41 release!
>>
>> The binutils-2_41 tag has
>>
>> m4_define([BFD_VERSION], [2.40.90])
> 
> Darn.  I am not sure that I can do anything about this.
> 
> I must have missed running "git commit; git push" after changing
> bfd/version.m4 to:
> 
>   m4_define([BFD_VERSION], [2.41])
> 
> And then making the source release tarballs.  So the tarballs are
> OK but the tag points to an earlier version of the sources, just
> before the release happened.  The problem is, there is no commit
> that exactly corresponds to the released sources, so I cannot create
> a new tag for the release point.
> 
> Any ideas ?
> 
> Cheers
>   Nick

If we don't have to stick to the "binutils-2_41-branch", we could just
create real 2.41 commit, making the commit 2c73aeb8d2e0 ("The 2.41
release!") parent, then change the tag (the resulting commit will not be
a part of any branch).  That should create a duplicate diff to commit
7872e3bdb0de ("Reset 2.41 branch back to development mode") in the 2.41
branch but far better than "no real 2.41 on the repository".

Alternatively, we have an option to release 2.41.1 and yank the original
2.41(.0) (the SemVer way).  But that's probably overdoing.

Thanks,
Tsukasa

> 
> PS.  I have updated the README-how-to-make-a-release file to add
>   a note to check for pending commits just before creating the source
>   tarballs, so hopefully this issue will not happen again in the
>   future.
> 
>