Le jeudi 30 avril 2020 à 00:38 +0200, Miro Hrončok a écrit : > > My sentence was about "python3.9" not being more annoying than > "python-3.9". > > I wonder, why do you consider periods in names confusing? … > jboss-jsf-2.1-api Another example where the hyphen helps reading. The version is mid package name (that can easily happen when the SRPM is versionned but subpackages not), and the hyphens nicely separe a version qualifier from the rest of the name. That means, a parser (human or not) can match -numeric- and not be confused by 0ad, go2rpm, 0install, cookies4all, etc where there are some numeric elements in the middle of the upstream name, but they are not versions as such. Old human languages did not use word separators like space in writing, because "everyone knew" where one word started and the next finished. Even scholars that spent their life studying one of those past civilization find them endlessly confusing by today’s standards. And yes, I am quite sensitive to the regularity of version syntax by now, after years of trying to align the git non-idea of a version¹, the various forges "straightening up" of git non-ideas, the go interpretation of all of the above, and the rpm idea of a version, in Fedora macros. And don’t get me started on pseudoversions (all the above kinds) here. Clever “it’s obvious in the few cases we imagine today, we do not need a clean version separator” syntaxes fail hard once exposed to the real world. Regards, ¹ Linus did not bother with a clean version reference in git. People build sand castles on one man page example where Linus workarounds his own tooling defficiency by using vx.y as tag in an example. That means in git, the vxx.y tag is probably a version, vampire is probably not, vnumericsomething may be a version with some made up pre/post release garbage at the end, or something else entirely. All because Linus did not bother defining a clean version separator but reused the v letter, because “it was obvious” in the limited use cases he imagined. -- Nicolas Mailhot _______________________________________________ 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