Examples of Semantic Version Names

Question

I have been reading about semver. I really like the general idea. However, when it comes to putting it to practice, I feel like I'm missing some key pieces of information. I'm not sure where the name of a library exists, or what to do with file variants. For instance, is the file name something like [framework]-[semver].min.js? Are there popular JavaScript frameworks that use semver? I don't know of any.

Thank you!

Answer 1

Let me try to explain you. If you are not developing a library that you like to keep for years to come, don't bother about it.. If you prefer to version every development, read the following.

Suppose you are an architect or developer developing a library that is aimed to be used by hundreds of developers over time, in a distributed manner. You really need to be cautious of what you are doing, what your developers are adding (so interesting features that grabs your attention to push those changes in the currently distributed file). You dont know how do you tell your library users to upgrade. In what scenarios? People followed some sort of versioning, and interestingly, their thoughts all are working fine.

Then why do you need semver ?

It says "There should be a concrete specification for anything for a group of people to follow anything collectively, even though they know it in their minds". With that thought, they made a specification. They have made their observation and clubbed all the best practices in the world about versioning software mainly, and given a single website where they listed them. that is semver.org. Its main principles are :

Imagine you have already released your library with a version "lib.1.0.98", Now follow these rules for subsequent development.

Let your library is bundled and named as xyz and,

Given a version number MAJOR.MINOR.PATCH, (like xyz.MAJOR.MINOR.PATCH), increment the:

 1. MAJOR version when you make incompatible API changes

(existing code of users of your library breaks if they adapt this without code changes in their programs),

 2. MINOR version when you add functionality in a backwards-compatible manner 

(existing code works, and some improvements in performance and features also), and

 3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

If you are not a developer or are not in a position to develop a library of a standard, you need not worry at all about semver.

Finally, the famous [d3] library follows this practice.