- For Python (or PyPI) this is easier, since their data is available on Google BigQuery [1], so you can just run
SELECT * FROM `bigquery-public-data.pypi.distribution_metadata` ORDER BY length(version) DESC LIMIT 10
The winner is: https://pypi.org/project/elvisgogo/#historyThe package with most versions still listed on PyPI is spanishconjugator [2], which consistently published ~240 releases per month between 2020 and 2024.
[1] https://console.cloud.google.com/bigquery?p=bigquery-public-...
[2] https://pypi.org/project/spanishconjugator/#history
by jonchurch_
0 subcomment
- The author has run into the same problem that anyone who wants to do analysis on the NPM registry runs into, there's just no good first party API for this stuff anymore.
It seems this was their first time going down this rabbit hole, so for them and anyone else, I'd urge you to use the deps.dev Google BigQuery dataset [0] for this kind of analysis. It does indeed include NPM and would have made the author's work trivial.
Here's a gist with the query and the results https://gist.github.com/jonchurch/9f9283e77b4937c8879448582b...
[0] - https://docs.deps.dev/bigquery/v1/
- > there are over 2800 legacy mixed-case packages, many of which have the same spelling as other existing lowercase packages
This is insane
by sundarurfriend
2 subcomments
- The Julia General registry is locally stored as a tar.gz and has version info for all registered packages, so I tried this out for Julia packages. The top 5 are:
DiffEqBase 6.189.1
LoopVectorization 0.12.172
Reactant 0.2.161
Mooncake 0.4.159
Distributions 0.25.120
So, no crazy numbers or random unknown packages, all are major packages that have just had a lot of work and history to them. Out of the top 10, pretty much half were from the SciML ecosystem.Caveats/constraints: Like the post, this ignores non-SemVer packages (which mostly used date-based versions) and also jll (binary wrapper) packages which just use their underlying C libraries' versions. Among jlls, the largest that isn't a date afaict is NEO_jll with 25.31.34666+0 as its version.
by aragonite
3 subcomments
- Incidentally I once ran into a mature package that had lived in the 0.0.x lane forever and treated every release as a patch, racking up a huge version number, and I had to remind the maintainer that users depending with caret ranges won't get those updates automatically. (In semver caret ranges never change the leftmost non-zero digit; in 0.0.x that digit is the patch version, so ^0.0.123 is just a hard pin to 0.0.123). There may occasionally be valid reasons to stay on 0.0.x though (e.g. @types/web).
- Anthony Fu’s epoch versioning scheme (to differentiate breaking change majors from "marketing" majors) could yield easy winners here, at least on the raw version number alone (not the number of sequential versions released):
https://antfu.me/posts/epoch-semver
by nosefurhairdo
3 subcomments
- The "winner" just had its 3000th release on GitHub, already a few patch versions past the version referenced in this article (which was published today): https://github.com/wppconnect-team/wa-version
by whilenot-dev
3 subcomments
- > Time to fetch version data for each one of those packages: ~12 hours (yikes)
The author could improve the batching in fetchAllPackageData by not waiting for all 50 (BATCH_SIZE) promises to resolve at once. I just published a package for proper promise batching last week: https://www.npmjs.com/package/promises-batched
- > I was recently working on a project that uses the AWS SDK for JavaScript. When updating the dependencies in said project, I noticed that the version of that dependency was v3.888.0. Eight hundred eighty eight. That’s a big number as far as versions go.
It also isn’t the first AWS SDK. A few of us in… 2012 IIRC… wrote the first one because AWS didn’t think node was worth an SDK.
by athrowaway3z
1 subcomments
- One of the 'winners' I randomly googled.
> carrot-scan -> 27708 total versions
> Command-line tool for detecting vulnerabilities in files and directories.
I can't help but feel there is something absurd about this.
by EdSchouten
3 subcomments
- So 19494 is the largest? That's far lower than I expected. There's nobody out there that has put a date in a version number (e.g., 20250915)?
- Large number of released packages due to renovatebot / dependabot patching + release automation!
If this was an actual measurement of productivity that bot deserves a raise!
- I wonder if the author could have replicated the couchdb database locally to make their life easier.
- I'm glad "all-the-package-names" includes "all-the-package-names"
But what if it was "all-the-package-names-that-do-not-reference-themselves"?
- > 46. aws-sdk -> 1692 (2.1692.0)
AWS still made the top 50
- `latentflip-test` is from the same fellow who did the "What the heck is the event loop anyway?" JSConf EU talk that many have seen. https://youtu.be/8aGhZQkoFbQ
by zastai0day
0 subcomment
- Haha, good luck finding a real project that holds that title. It's always some squatted name, a dependency confusion experiment, or a troll publishing a package with version 99999.99999.99999 just to see what breaks. The "king" of that hill changes all the time. Just another day in the NPM circus.
by kubatyszko
0 subcomment
- the one with -1 obviously ;)
- https://cpan.metacpan.org/modules/01modules.index.html
Bigliest, boomiest version is 3735928560 from https://metacpan.org/dist/Acme-Boom
by huflungdung
0 subcomment
- [dead]
Hacker News