>>>> DNF-2 release candidate will land into rawhide. It will bring many new >>>> features and bug fixes. DNF-2 is using libdnf instead of hawkey or >>>> libhif. Unfortunately it brings some incompatibilities with previous >>>> version which were either needed to preserve compatibility with yum >>>> CLI or where bigger redesigns were needed (parsing command line >>>> arguments). If you own any DNF plugin or component depending on DNF, >>>> please, see the DNF-1 and DNF-2 changes [3] and adjust your package >>>> accordingly. Moreover bump the DNF requirement as DNF honors semantic >>>> versioning [4] to prevent future breakage when another major version >>>> is deployed. To majority of components requiring >>>> DNF in Fedora repository were sent patches to adapt them to DNF-2. >>>> >>> >>> Sounds like this scope would warrant a Change? >> >> The components should be already prepared for DNF-2 and the changes >> are not huge. There's the FESCO ticket [5]. If it is not accepted then >> we will submit a Change. >> > > Actually, the preferred approach would be for this to come to FESCo *as* a > Change. Mostly because the Change Process requires you to explain the situation > fully and establish a contingency plan. Completely agree, we (rel-eng and I'm sure others) don't want to find out one day everything is broken due to this change and the compose is up the spout. Core components such as dnf need to follow the process properly and communicate far and wide so people are aware of the changes in flight that could affect everything from builds to users updating. Peter -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
