Re: [PATCH] wincred: align Makefile with other Makefiles in contrib

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 7, 2025, 16:30 UTC
Message-ID: <xmqqwm41g605.fsf@gitster.g>
In-Reply-To: <19573251-81e1-e07d-0f21-1f90ea5153a3@mailbox.tu-dresden.de>

Thomas Uhle <thomas.uhle@mailbox.tu-dresden.de> writes:

> Thank you!  Does this patch qualify for the final version 2.52.0 or is it 
> already too late?  And if it is the latter, wouldn't it make sense to have 
> it in an updated version 2.52.1?

Highly unlikely, I would suspect.

In general, after -rc1 gets tagged, nothing will become candidate for the final release without a valid excuse. One common reason is that it is a bugfix for a regression that was introduced during the cycle. This clearly isn't one---the aspect of the wincred Makefile your patch fixes haven't changed since ccfb5bda (wincred: add install target, 2012-10-24). People lived with that awkwardness for 13 years. They can live with it a few more months just fine.

Those who _have_ been building wincred and installing it for their own (or for their colleages) would have an established procedure to work around the unusual arrangement the Makefile has (which you have fixed), and changing it this close to the final release would only add extra work on them, without helping anybody else. A good time to merge such a change is early in a fresh cycle, so that they have longer preparation period to adjust their build infrastructure.

There are reasons we may want to have changes newly floated after -rc1 got tagged; for example, I merged 8d716966 (ci: update {download,upload}-artifact Action versions, 2025-11-06) after tagging -rc1. There were another CI fix merged immediately before -rc1.

The benefit any late changes that get merged has to outweigh the risks by a large margin, and CI changes like these have very small blast radius even if it goes wrong (nobody other than our developers would be affected, and they know what to do) while the damage unfixed CI job can cause is larger (CI can deliberately stop to make us realize that the service we rely on is being deprecated).

There also is a message typofix merged post -rc1, to correct new messages that appeared during this cycle. The output from the programs before the release candidate were properly localizable, but left unfixed, our translators need to translate typoed messages, and then when the typofix hits 'master' later, they have to adjust their translations by updating what original gets translated again.

Is there comparable justification why wincred/Makefile change has to be in the upcoming release? I do not think of any.