From 3db83e48d5bd7d52a7f8a28601895c61f67048c2 Mon Sep 17 00:00:00 2001
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Date: May 08 2023 09:15:00 +0000
Subject: Drop discussion of builds in older branches with %autorelease


There is a disagreement how to proceed with "rebuilds in older branches":
- rpmautospec does not really support adding a minor bump.
  ('%{autorelease -b 0}.' sets the Release correctly, but %autochangelog
   is generated as if '-b' was not set, so the release fields disagree.)
- But even if it could be made to work, it is quite inconvenient, so it's
  not clear if is worth the trouble. (In my opinion — no.)
- We could either ask people to rebuild,
- Or we could remove the requirement to have a higher version-release
  in later releases,
- Or we could tweak that rul to only require a higher version, but
  allow a lower release. If we do this, we might want to adjust tooling
  to only warn about version downgrades, but silently allow release
  downgrades.

A quick check using 'dnf repoquery' shows that there are packages
using minorbumps, but it also seems that the majority are doing that in
error:
  $ dnf repoquery --releasever=37 --qf '%{name}-%{version}-%{release}' \
    '--disablerepo=*' '--enablerepo=updates-source' '--enablerepo=fedora-source' \
    --arch=src | rg 'fc37.\d' | wc -l
  96

  $ dnf repoquery --releasever=37 --qf '%{name}-%{version}-%{release}' \
    '--disablerepo=*' '--enablerepo=updates-source' '--enablerepo=fedora-source' \
    --arch=src | rg 'fc38.\d' | wc -l
  83

Considering that F38 hasn't been released yet, those 83 packages should
not be using minorbumps. So there's probably ≤13 packages in F37 using
a minorbump as intended.

So let's remove this subsection for now, so that the other part of the
changes can be merged, and discuss how to handle this case separately.

---

diff --git a/guidelines/modules/ROOT/pages/Versioning.adoc b/guidelines/modules/ROOT/pages/Versioning.adoc
index b4e7b7e..5ed52c0 100644
--- a/guidelines/modules/ROOT/pages/Versioning.adoc
+++ b/guidelines/modules/ROOT/pages/Versioning.adoc
@@ -370,20 +370,6 @@ In this case the full N-V-R could be e.g. `pkg-1.1.0.20210105.SP1_CP1-1.fc{CURRE
 
 In this case the full N-V-R could be e.g. `pkg-1.0.1.security1^20210301gabc0202-1.fc{CURRENTVER}`.
 
-== Only an old branch needs a change
-
-Sometimes, an older branch needs a fix, but the newer branches are fine.
-For example, both F{PREVVER} and F{CURRENTVER} are built from the same dist-git commit,
-and only F{PREVVER} needs a fix.
-If only F{PREVVER} was changed, its `Release` would increase
-and thus the E-V-R for F{PREVVER} would sort higher than E-V-R in F{CURRENTVER}.
-To avoid this situation, rebuild the package also in the later branches,
-possibly with just an empty commit to make `%autorelease` bump the release.
-
-If the package does not use `%autorelease`,
-you **may** rebuild just the older branch,
-see <<Rebuilds in older branches using `<minorbump>`>>.
-
 [#traditional-versioning]
 == Traditional versioning with part of the upstream version information in the Release field