Please keep the command name "yum", and keep the command line syntax and the configuration language as compatible as is feasible. Make a wrapper or a symlink if you need to, but plan to keep it forever, not just for a year or two. So Yum has been made faster? That's wonderful news, it was certainly needed. It's been redesigned and largely rewritten? OK, great, I understand that the new design is better. If there was some feature that turned out to be a misfeature and had to be removed, well that's unfortunate but it happens. Remove the misfeature, document that it's gone and that it was a bad idea from the beginning, and print an informative error message when someone tries to use it. If a feature that was optional before is now always enabled, then keep the option as a no-op and document that it has no effect anymore. As a user of Yum I don't see any of that as a reason to change the command name. As a system administrator I expect "yum install", "yum remove" and "yum update" to continue to work, and I expect to not have to rename or edit /etc/yum.conf after an upgrade. I'm sure I'm far from alone. As a fellow programmer I can understand that you want to use a new name for this new and improved program that you have invested a lot of work in, but I also know how annoyed I would be if I had scripts calling Yum, and had to modify them to keep them working. A command line interface is also an API, and I want APIs to be as stable as possible so I can spend my time writing new programs instead of rewriting old programs just to keep existing functionality. It's particularly painful when a program must be ported or branched to work on different systems, for example Fedora and RHEL, because one has only the old API and the other has only the new API. -- Björn Persson
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
