amrein Messages: 278 Registered: August 2008 Location: France
Experienced Member
mirek wrote on Tue, 14 April 2020 13:38
I have fixed the poll to make it more clear...
Still, I think that there is no reason to sacrifice compatibility. The differences in what is possible without sacrificing it and what is possible while doing so are IMO negligible.
EDIT: Actually, the only meaningfull difference there is that you insist that 3rd non-option parameter is "output", while backward compatibility requires "build method" (which you want to supply with -b only). Is that really worth it?
Mirek
"Should we upgrade umk command line behavior" => "Should we sacrifice backward compatibility in umk to make command line nicer?"
It's clearly a more oriented question. Only early adopters who adapt easily to new things will say "yes, we should".
And personally, my understanding of this modified question is: "Should we break umk or not".
It's important to note that at present, noone has replied "I depends on umk current behavior and I can't stick with an older binary".
Members
Pages
Help
Register
Login
Home
