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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to