Bug 1684716 - 1.5 in rawhide/f30 1.7 in f29 - System upgrade to 30 downgrade
Summary: 1.5 in rawhide/f30 1.7 in f29 - System upgrade to 30 downgrade
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kronosnet
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: digimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-01 22:30 UTC by Phil Wyett
Modified: 2019-04-11 17:02 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-11 17:02:25 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.