You've read the README, scanned the issues, and looked at how the team handles pull requests. Now you want to know something more fundamental: is this project actually alive? And how stable is what they've built?
Commits and releases answer both questions.
Commits: the work trail
Every time someone records a change to the codebase, that snapshot is called a commit. Each commit has a short description (the commit message), a timestamp, and the name of the person who made it.
Find them by clicking the Commits link on the repository's main page. It sits near the top, showing a count like "1,432 commits". Click it and you'll see the full history, newest first.
You're not here to read the code. You're here to read the pattern.
A healthy project looks like a steady drumbeat. Commits spread across weeks and months, from multiple contributors, with messages that describe real work: "fix edge case in file parser", "update dependency versions", "add support for new API endpoint". Not glamorous, but that's the point. Maintenance is what keeps software working.
A stalling project shows a different pattern. Lots of activity two years ago, a handful of commits six months ago, nothing since. That pattern could mean the project is mature and stable, or it could mean it's quietly dying. You need the releases section to tell the difference.
Watch for these signals:
Commit frequency. A burst of activity followed by long silence is different from steady work over years. The burst might mean someone built it for a specific purpose and moved on. You want to see the drumbeat, not the fireworks display.
Commit messages. Vague messages like "fix stuff" or "update" suggest low discipline. Clear messages suggest a team that cares about their own history. Small signal, but real.
Releases: the stable moments
Commits show the daily work. Releases show the moments the team decided something was ready for the world.
Find releases in the right sidebar of the main repository page, labeled Releases. Click through and you'll see a list of versions, usually numbered like v1.2.0 or v2.0.0-beta, each with a date and release notes explaining what changed.
A release is a declaration. It says: this version is stable enough that we're willing to put our name on it and tell users to trust it.
What you want to see:
Recent releases. How recent matters depends on what the project does. Fast moving AI tooling that hasn't shipped in eighteen months is probably behind. A small utility library that does one thing well might go years without a release and be perfectly fine. Ask whether the software's job has changed recently. If yes, no recent release is a concern.
Release notes that mean something. Good release notes describe what changed, what was fixed, and sometimes what was broken in previous versions. Thin or absent release notes suggest a team that doesn't think carefully about the people depending on their work.
Version numbers. A project on v0.3.1 is signaling it doesn't consider itself production ready. That's worth knowing if you're relying on it for something important. But treat version numbers as one signal, not a verdict. Some mature, well maintained projects stay below 1.0 by choice. Some projects ship 2.0 and still break constantly.
A gap between commits and releases. If the last release was two years ago but commits are happening weekly, the team may be sitting on unreleased work. That's worth noting. It could mean they're building toward a big release, or it could mean their release process is broken.
Reading both together
Commits and releases are most useful in combination.
Active commits plus recent releases: the project is alive and people are shipping. Good sign.
Active commits but no releases in years: active development, but nothing stable to depend on. Proceed carefully.
No commits, no recent releases: effectively abandoned. Someone might fix a critical security issue if pushed, but don't count on it.
A flood of commits right before a release, then silence for months: a sprint project. Built for a deadline, not maintained for the long run.
None of this tells you whether the code is good. But it tells you whether anyone is home. For most purposes, that's the question that matters first.