Dne 21. 12. 22 v 18:45 Chuck Anderson napsal(a):
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.
Luckily the former should be the case, IOW `dnf` command stays. Vít
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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
