Open Source Project Release Tracking
Repository releases, maintainership changes, licence revisions and the abandonment signals that matter more than any version number.
Open source projects publish more legible release information than any other kind of software. Tags are public, changelogs are generated from the commits that produced them, and the discussion that led to a change is usually readable alongside it. If you want to know exactly what shipped, this is the one category where you reliably can.
What that visibility does not give you is the health of the project, and health is what determines whether depending on it is wise. A steady release cadence, several active maintainers and a responsive issue tracker are the signals worth watching. Their absence is equally informative, and far easier to miss — nothing is published when a project stops being maintained.
What this category tracks
- Repository releases
- Tagged releases with their generated notes, across major and minor versions and security patches.
- Licence changes
- Relicensing announcements and changes to the terms under which a project may be used.
- Maintainership and governance
- Maintainer changes, foundation transfers, forks and governance restructures.
- Archival and deprecation
- Projects marked archived or read-only, and official recommendations of a successor.
- Security advisories
- Advisories published against a project, and the release that closes each one.
What matters most here
Relicensing is the event with the sharpest consequences and the least warning. A project changing from a permissive licence to a source-available one does not break the build — the version you already have keeps working under the terms it shipped under — but every subsequent upgrade lands under new terms. Because the announcement is a single post and the code carries on functioning, this is routinely discovered long after the decision point has passed.
Where this data comes from
- Public repository release tags and generated release notes
- Project security advisory databases
- Official project blogs, governance announcements and licence notices
- Package registry version metadata
Every indexed entry links to its primary source. See our editorial and sourcing policy for what we verify and what we do not.
Common questions
How do you tell an abandoned project from a stable one?
You often cannot from release data alone, which is worth being honest about. A mature library may go a year between releases because nothing needs changing. What distinguishes it from abandonment is issue and pull request activity, not release frequency — so treat a long gap as a prompt to look, not a conclusion.
Are forks tracked as separate projects?
Where a fork publishes its own releases and is presented as a continuation, yes. A fork that becomes the maintained line while the original goes quiet is one of the more consequential things that can happen to a dependency, and it deserves its own record.
Tracked releases in Open Source Projects
The live release list for this category loads below.