文章摘要
作者在使用AWS SDK for JavaScript时，注意到其版本号为v3.888.0，这引发了他对npm注册表中哪个包拥有最大版本号的好奇。他计划通过npm API查询所有3,639,812个包的版本号，找出其中最大的数字，无论是主版本、次版本还是修订版本。
文章总结
npm包中版本号最大的包是哪个？
作者在更新项目依赖时，注意到AWS SDK for JavaScript的版本号为v3.888.0，这引发了他的好奇心：在npm注册表中，哪个包的版本号最大？无论是主版本、次版本还是修订版本，只要在<major>.<minor>.<patch>格式中有一个数字最大即可。
为了找到答案，作者首先尝试通过npm的API获取所有包的版本信息。npm注册表中有超过360万个包，作者通过CouchDB的_all_docs端点获取了所有包的ID，并分批获取了每个包的元数据。整个过程耗时约12小时，最终生成了约886MB的数据文件。
在分析数据后，作者发现版本号最大的包是latentflip-test，其版本号为1000000000000000000.1000000000000000000.1000000000000000000。然而，这个包显然没有遵循语义化版本控制（SemVer），因此作者决定进一步筛选出遵循SemVer的包。
最终，作者发现all-the-package-names包的版本2.0.2401是遵循SemVer的包中版本号最大的，其最大数字为2401。尽管这个结果有些出乎意料，但作者认为这是一个有趣的发现。
主要步骤：
1. 通过CouchDB的_all_docs端点获取所有npm包的ID。
2. 分批获取每个包的元数据，提取版本信息。
3. 筛选出遵循SemVer的包，并找出其中版本号最大的包。
结果：
- 版本号最大的包（不遵循SemVer）：latentflip-test，版本号为1000000000000000000.1000000000000000000.1000000000000000000。
- 遵循SemVer的包中版本号最大的包：all-the-package-names，版本号为2.0.2401。
总结：
尽管有些包的版本号非常大，但大多数情况下这些包并没有遵循语义化版本控制。通过这次探索，作者发现all-the-package-names是遵循SemVer的包中版本号最大的包。
评论总结
评论主要围绕软件版本号的多样性和复杂性展开，涉及不同编程语言和包管理系统的版本管理实践。以下是主要观点和论据的总结：
版本号的多样性与荒谬性：
- 一些评论指出某些软件包的版本号异常高，甚至达到数千或数万，如“carrot-scan”有27708个版本（评论6）。
- 评论10提到，高版本号往往是一些实验性或恶搞性质的包，而非实际项目。
版本管理的技术挑战：
- 评论5提到，获取大量包的版本数据耗时过长，建议通过改进批处理来优化性能。
- 评论4讨论了SemVer规范下0.0.x版本的特殊性，指出依赖管理可能存在的问题。
不同语言的版本管理实践：
- 评论8指出，Python的PyPI数据可通过Google BigQuery查询，展示了版本号最长的包和发布频率最高的包。
- 评论13提到Julia包的版本管理，展示了几个主要包的版本号，并指出这些包因长期开发而积累了较高的版本号。
自动化工具对版本号的影响：
- 评论9指出，自动化工具如renovatebot和dependabot的大量修补和发布自动化可能导致版本号激增。
版本号的创新与争议：
- 评论7提到Anthony Fu的“epoch versioning”方案，旨在区分重大变更和“营销”版本号。
- 评论11质疑为何没有使用日期作为版本号，认为19494的版本号远低于预期。
总结：评论反映了软件版本管理的复杂性和多样性，涉及技术挑战、自动化工具的影响以及不同语言的实践。高版本号往往引发争议，而创新版本管理方案也在不断涌现。