I asked myself one question: “How do I elevate my coding skills?” After some thorough research, one of the many answers is to study and analyse large open-source codebases. Why would you want to do that? Well, you learn from the best, people who know what they are doing.

And understanding a large codebase is not easy, but not impossible; it takes patience and commitment. So I tried to find ways to help me analyse and study, and that’s when I came across releases and tags on GitHub for large open-source projects.

Now, this is where Semantic Versioning comes into the picture. You can go back to any point in time for releases and tags.

Knowing this, you can go back to the first release of any codebase that has releases. It’s a good start to learn how the codebase is initialized and evolves and the decision-making that is involved.

A simple example of Semantic Versioning:

1. v1.0.0: Initial release of the API with the /books endpoint, providing basic book information.

2. v1.1.0: Added a new endpoint, /authors, to retrieve information about book authors. (Minor version bump because it’s a new feature, but existing clients relying on /books are unaffected.)

3. v1.1.1: Fixed a bug in the /books endpoint that caused inaccurate results when searching by title. (Patch version bump for a bug fix.)

4. v1.2.0: Introduced the /genres endpoint to categorize books by genre. (Minor version bump for a new feature, but existing clients are unaffected.)

5. v2.0.0: Renamed the /books endpoint to /publications, introduced a completely different data structure in the response, and deprecated the old /books endpoint. (Major version bump due to a breaking change.)

6. v2.1.0: Added a /recommendations endpoint to suggest books based on user preferences. (Minor version bump for a new feature, but existing clients are unaffected.)

7. v2.1.1: Fixed a bug in the /publications endpoint that caused unexpected behavior. (Patch version bump for a bug fix.)

8. v2.2.0: Improved performance in the /publications endpoint by optimizing the database queries. (Minor version bump for performance improvement.)

In this example, clients using the initial API version (v1.0.0) may need to make changes to adapt to the renamed endpoint and new data structure introduced in v2.0.0, so that’s why it’s a major version bump. Minor and patch version changes ensure that new features and fixes are introduced in a backward-compatible manner, allowing existing clients to continue working without modification.

Be patient in your journey to study and analyse large, open source codebase. Good things take time.

About me:

Hey, my name is Ramu Narasinga. I study large open-source projects and create content about their codebase architecture and best practices, sharing it through articles, videos.

I am open to work on interesting projects. Send me an email at ramu.narasinga@gmail.com

My Github —  https://github.com/ramu-narasinga

My website —  https://ramunarasinga.com

My Youtube channel —  https://www.youtube.com/@ramu-narasinga

Learning platform —  https://thinkthroo.com

Codebase Architecture —  https://app.thinkthroo.com/architecture

Best practices —  https://app.thinkthroo.com/best-practices

Production-grade projects —  https://app.thinkthroo.com/production-grade-projects