When developing a project, part of your work as a developer will be to document and version your code. Have you ever noticed those numbers like 2.3.1 or 1.0.4? They aren't randomly defined! They're defined by a convention called Semantic Versioning.
What is Semantic Versioning?
You're developing or already have a super useful JavaScript package that other developers are using in their projects. Every new feature you implement in your package or every bug you fix needs to be communicated to the people using your package.
How should I do it?
This is where Semantic Versioning helps you! It breaks down the version number of your package into three parts: X.Y.Z.
X is the major version. This changes when you make changes that can break the code of people using your package.
Y is the minor version. This changes when you add a new feature but don't break people's code.
Z is the patch version. This changes when you fix a bug but don't change anything that people are already using.
Let's make it even easier for you to understand with these examples:
- Do you release the first version of your package? 1.0.0.
- Added a new feature? 1.1.0.
- Fixed a bug? 1.1.1.
- Made big changes that could break people's code? 2.0.0.
- Fixed a bug in the new version? 2.0.1.
This way, everyone can clearly understand the impact of changes in your package or project. Remember to also explain in your README what's new in your changes.
Top comments (0)