版本号中 4.9 大于 4.15 的第一想法是如何运转出来的？

4.9 再往上发版的时候变 5.0

因为语义化版本号不能补 0，所以经常和小数混淆
三位还好办，两位只能看历史版本规律或者靠猜了

我现在才意识到数字上 4.15<4.9,上一个贴我看完标题的反应是“这不是很明显 4.15>4.9 吗”
流程可能是这样的，两边都是 4，4 和 4 约掉，然后 15>9

4.9.9.9.9，就是不发布 4.10

4.09
4.15

@luob python 的 html5lib 版本号 0.9999999999999 …

一开始我也没看懂， 后来听人念出来之后我就再也没糊涂过了，四点十五，四点九，很明显十五大哈哈

我很好奇为啥发的时候不发 4.09 ....

因为 4.9 不是十进制数
不是十进制数
不是十进制数
所以.9 不会再升一位

在苹果这边，你发了 4.9，之后是发不出 4.15 的
我这边都是最好加个 4.09

@vocaloid #8 发 4.1 4.2 的时候并不能确定是否有 4.10+的版本，也就没有必要预留两位。万一版本数超过 99，达到了 4.100 ，是不是要预留 3 位，从最开始就发 4.001 呢

？？？，我是没看懂吗？按点分割，按分割后按结果比较不就行了？

拆解喽……比如 Version 5.1.18362.145:
Major version: 5
Minor version: 1
Build: 18362
Revision: 145

要不然就 4.90 要不 4.1.5，不然小数点后面有一位有两位的不好比较

所有 ci cd tool 里 x.9 之后都是 x.10

小数点是分隔符，我是这样理解的

讨厌这种容易引起歧义的版本号，每次都要靠日期才能判断到底哪个是新的。

@loveuqian 你确定苹果不行？你要不再试试？

“如何看出来”？如果大脑无法分辨出来，可以借助 shell

GNU sort 有一个 -V 比较版本选项

echo -e "4.15\n4.9" | sort -V
4.9
4.15

如果不方便使用 GNU 扩展。还有就是把取出 . 分割的全部数字，然后补 0 到 3 位，再 sort -n

比如 printf "%03d%03d" `grep -Eo '[0-9]+\.[0-9]' | tr '.' ' `'

再阔展一下小数点。
下次版本改成
4.15.00
然后慢慢的把旧版本统一称呼为 4.9.00

明显是数据库用了小数存储

因为点.dot 这个东西在这里不是小数点

4.9=4+90/100
4.15=4+15/100

所以 4.9 是大于 4.15 的。
为了方便比较就不约分了。

这就是有的地方要出 4.9 之后，就不允许再出 4.1x 的原因了。
判定的话就是记得在判断版本号的时候整数位划了，完了直接比后面。
不过不建议非得用这种版本号。很容易混乱。

我觉得这个问题不成立，至少题主说了是版本号的情况下我没觉得 4.9 比 4.15 大。
当然我默认大家都了解语义化版本号： https://semver.org/lang/zh-CN/

@liuzhaowei55 了解不代表习惯，我认为它那个前面不能补 0 的规定就很扯淡，所以我自己项目小版本号从来不超过 9

semver

还是约束不够好 4.15.0 和 4.9.0 就很明显了

4.15 是两个数字，一个是 4,一个是 15,分别比较，不是比较字符串

4.15 并不是传统意义的浮点数，.点只是一个分隔符

内核 4.15 大于 4.9 版本啊

看错了，尴尬…

版本号是：major.minor.patch
或者
major.minor

“ major ”, “ minor ”, “ patch ” 都是独立的 Int 类型。

判断版本的时候，请用 "." 去做 split。 然后分别对每个部分进行 Parse Int。

https://semver.org/

有的项目已经开始用日期代替版本号了

以日期作为版本号市最科学的

@MarginK
确定啊，亲身经历过啊，除非是又有了修改

@deorth #34
@efaun

同时维护多个大版本时还是需要这种版本号，例如 python 2、3 php5、7。

慌了，我也要想半天才能想到哪个大哪个小。

4,9 和 4,15 是不是就不会搞混了？
这个点不是小数点，是分隔符。

多用这种方式，熟悉了就好了呗