On 2021-02-25 10:13:24-0800, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > > > Usually we can only use `format-patch -v<n>` to generate integral > > version numbers patches, but if we can provide `format-patch` with > > non-integer versions numbers of patches, this may help us to send patches > > such as "v1.1" versions sometimes. > > I am not in principle opposed to support a fractional version number > that comes after an integral one, which allows users to signal that > it is a minor correction that does not deserve a full version bump. I'm late into the party, but this rational sounds greate to me. > If we were to do this, I would probably suggest a preliminary patch > that refactors the hardcoded "reroll_count - 1" out of diff_title() > so that the helper takes two "reroll count strings", i.e. reroll > count for this round, and the previous round, as two separate > parameters. Teach the caller to pass "reroll_count - 1" for the new > parameter in this preliminary step. However, if it's only a minor correction to the major version, I _think_ it makes better sense to compare with the major version instead of comparing with another minor version. When a reviewer reviews v3.5, they can just compare to v3. In a hypothetical world, when another reviewer jump in and a major change required, v4 reroll also compare with v3. In other words, we will have something likes: - v3 vs v2 - v3.1 vs v3 - v3.2 vs v3 .... - v4 vs v3 The good side of this approach is: the logic to choose previous version is simple. The downside of this approach is: reviewers need to re-read the changes in v3.1 v3.2, etc... However, we can reasonably expect those changes are small enough, they're minor changes after all. And they will need to re-read all the change if the major verison was increased. -- Danh
