Am 04/07/2024 um 14:11 schrieb Fiona Ebner: > There is no apiinfo call required anymore. No code is the cleanest kind
Yeah, by the assumption you self choose to use and that I question, so not really a useful argument. In practice, users can upgrade a from one major release to the next one, nothing is really blocking them w.r.t apt, that cannot be said for jumping releases, so one should definitively have different levels of standard for "any X to any X + 1" compared to "X to X + >= 2". What we recommend users (run latest 7 before upgrade) is not necessarily the exact same boundary of what we should hedge against to reduce negative feelings of users and resulting work/soothing our support has to do as a result; I'd think of it more like the minimum and recommended system requirements. > of code IMHO. Less code can be nicer as long as all features and edge cases are still handled properly and also still easy to read, not code golf minimalism. Or, to exaggerate for the points' sake, should I just delete all our (user) error code handling and tell any users complaining that they just need to do it right the next time? While that would result in quite a few lines less, it definitively won't help our popularity. >> Besides that: no, I definitively place UX over some abstract "code >> cleanliness" >> criteria – if, it can be fair to set the barrier such that one should achieve >> both, but putting UX below code tidiness is IMO just not acceptable. > > I do put UX for users running ancient versions below code cleanliness, > but not UX for current versions of course. PVE 7 is still supported, so definitively not ancient! We normally put in quite a bit of work to ensure that systems talking with other incompatible versions get a good error, why bother adding versioning else in the first place? And while there's definitively areas that can still be improved, that's no argument for going backwards again. I mean this specific case here might be relatively harmless in effect, but if you really apply this philosophy to all development here then I wish you good luck into explaining angry users and our support agents that had to answer them, why it was good for them to remove some simple check for code cleanliness, because that should not be relevant if the users did everything 100% correct. We already need to justify us too much about not being hacky as a FLOSS solution, after having to use the shell occasionally any missing/incomplete error handling is the next big reason for people to complain. And sure, most alternative (proprietary) solutions are far from being better, and while it's annoying that some people are hypocrites here, I do not have anything against being held to a high(er) standard, as one can really stick out with good UX, which always consists of tons of little things. Anyhow, as mentioned, this might not fall back on us here, but I hope I could convince to not use that philosophy unconditionally, and I wished for some more background explanation on this in the commit message. I just cannot think that there could have any negative effect, be it in using nor maintaining that code for neither users nor developers, if we just fixed the actual (error handling) behavior of querying the API version instead, and possibly dropped the real old version checks, i.e. those not just a single major version apart, in a separate patch. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
