Bug 1684716

Summary:	1.5 in rawhide/f30 1.7 in f29 - System upgrade to 30 downgrade
Product:	[Fedora] Fedora	Reporter:	Phil Wyett <philip.wyett>
Component:	kronosnet	Assignee:	Madison Kelly <mkelly>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jpokorny, mkelly
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-04-11 17:02:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Phil Wyett 2019-03-01 22:30:36 UTC

Description of problem:

1.5 in rawhide/f30 1.7 in f29 - System upgrade to 30 downgrade.

Version-Release number of selected component (if applicable):

How reproducible:

Always

Actual results:

Downgrades package when upgrading from f29 to f30.

Expected results:

Should upgrade to latest version.

Comment 1 Jan Pokorný [poki] 2019-03-04 13:34:57 UTC

Note that since 2019-02-19, there's also a branched f30 branch, meaning
that both f30 and master shall receive the update.

IIRC, monotonicly increasing version throughout the Fedora releases was
explicit guarded in the past, not sure why this update:

https://bodhi.fedoraproject.org/updates/FEDORA-2019-318c6c9e2b

(f28 is still in testing, not pushed:
 https://bodhi.fedoraproject.org/updates/FEDORA-2019-50194f6eb4)

was allowed to become stable in the first place, since it would make
such equations not longer hold (misbehaviour of dist.rpmdeplint
check?).

* * *

Anyway, the typical workflow is:

1. start with master branch, which shall always be the tip
   (per the assumptions that used to get guarded explicitly
    in the past)

2. backpropagate the changes in master bracnh back to release
   branches, starting with the latest greatest (f30 now),
   preferably using "git merge --ff-only", stopping when you
   think you are back in history enough (generally, ABI must
   not break in the release branches, so if that's the case,
   change it in Rawhide only and announce the break on
   fedora-devel ML)

Following the step 2., you cannot get into this undesired state
that master (Rawhide) or generally newer release branches (f30 here)
carry older version of the package than some older distro releases
(f29 and possibly f28 here).

Comment 2 Phil Wyett 2019-04-11 17:02:25 UTC

This has been fixed with upload / move to 1.8.

Package quality is not good.