On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote: > [...] > > Let me put together a few points to sum this up: > > > > 1) DNF name is well established, keep the DNF name (and forget about YUM). > > > > 2) Keep the compatibility on reasonable level. 100% compatibility is myth > > (even between the tiniest updates). > > > > 3) Changes are inevitable, especially between major versions. That is why we > > version, right? While nobody likes them (especially breaking changes), they > > are accepted. Please don't be afraid to do them for good! > > > > 4) Keep the package name, so if somebody don't want to update, they can do > > `dnf update --exclude dnf` instead of looking for new package name to do > > `dnf update --exclude dnf5` > > > > 5) I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any > > user want to combine these, unless they are desperate. Don't bet everything > > on this. > > > > 6) Keep only one instance of documentation, if needed, document the old > > behavior > > > > 7) Tooling and framework changes on background are unimportant to end users. > > This is a very good summary of my opinion as well. Thanks, Vit! Is the command line tool for DNF version 5 called /usr/bin/dnf? Or will users have to learn to use "dnf5 install ..." etc? If the latter, I think it is a bad idea. Each time a new version of "ls" comes out, they don't append a new digit to the command. Users shouldn't have to learn a new command name just to upgrade to a new major version of a command. If the syntax and functionality is substantially the same, then the command name should remain the same. If the UX (user experience) is sustantially changed such that a user would have to learn a completely new syntax in order to use it, then perhaps it would be better to rename the whole product/command to something other than DNF. For example, when we moved from initscripts/service/chkconfig to systemd, the syntax changed enough that it made sense to have a new command "systemctl" to replace the previous commands "chkconfig" and "service". As for the RPM package name, that is less important because it doesn't really affect the UX much. Guidance here should be taken from the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple Examples: The python-sqlalchemy package occasionally has multiple versions in Fedora for backwards compatibility. The most current version of python-sqlalchemy is named python-sqlalchemy and an older supported version is python-sqlalchemy0.5. No delimiter is used in this situation. This seems to suggest that the package name should be "dnf" for the latest version and "dnf4" for the previous version. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
