RE: [BUGS] Git v2.51.2 on NonStop

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Oct 30, 2025, 16:02 UTC
Message-ID: <007501dc49b6$aacd9eb0$0068dc10$@nexbridge.com>
In-Reply-To: <729f9bbf-b75b-4161-b8aa-505ff906bb8a@app.fastmail.com>

On October 30, 2025 11:15 AM, Kristoffer Haugsbakk wrote:

Show 10 quoted lines

>On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
>> I have found new defects on 2.51.2 that were not present in 2.51.1
>> when building with OpenSSL 3.5 (probably unrelated).
>>
>> Many failures in t7900 resulting from the use of test_subcommand ! as
>> seen below. This is run in bash 5.0.18:
>>
>>[snip]
>
>Would it make sense for maintenance releases to have a small release

candidate pre-

>release?  Both of these maintenance releases have had issues.

Interesting question. I would personally prefer that maintenance releases would be fixes only, rather than new functionality or introduction of new dependencies or constructs that might break the main release. If there is something significant done, it should be in a main release, with a release candidate. I think we should be cutting down what is in maintenance releases so that release candidates are not required.

Obviously, if there is a CVE and we need a maintenance release to fix it, and the CVE has breaking changes, we have an issue - and if significant enough, then yes, a release candidate should be done.

Just my opinion, Randall