NPM: Semantic Versioning Characters

 

Semantic Versioning

Semantic versioning is a solution for the software management term of "Dependency Hell". A software usually depends on other software. 

But usually the "other" software also depends also on other products.


The illustration above shows a tree of dependencies. Like in the illustration, your software can depend on an other software in different versions.

To resolve issues like not to install same dependency multiple times or install the latest version of a software, there is a need of standardized software dependecy management. Semantic versioning standard offers tools like npm or yarn to resolve such dependencies.

📗 BASICS

A semantic version consists of three numbers seperated by a dot:
  • 1.1.1
  • Major Release.Minor Release.Patch Release

🥇Major Release: 2.1.1

You increase your version to a major release when 
  • your code has breaking changes 
  • the users of your software need to update their code, e.g an API change or sth else which has causes a major effect on the product using your software.

🥈Minor Release: 1.2.0

You increase your version to a minor release when 
  •  you release a new functionality
When you increase the minor version, you must reset the patch version to zero.

🥉Patch Release: 1.1.2

You increase your version to a patch release when 
  • you fix bugs
  • you patch the code
  • you have no changes in functionality

📏Ranges

You can also define that your software depends on a version range. That means e.g.
  • My software depends on a package with version 1.1.0
  • But the version up to version 1.7.5 works also
  • But package version 1.8.0 does not work
In this case you can tell the package manager that your software dependes on versions between 1.1.0 - 1.7.5.


🎯Playground

The npm page offers a really cool tool to test the versioning ranges:

Comments

Post a Comment

Popular posts from this blog

What is Base, Local & Remote in Git merge

Image
When you use a merge tool for Git and you have conflicts you often see these three versions of a file. This is called the three-way-merge. BASE LOCAL REMOTE So what are these files exactly? Imagine you have a branch. While you're working on the code, someone else has already changed the code in the main branch. Now you'll have a conflict if you merge your code into the main branch. The picture above emphasizes the points that are involved into the merge. GREEN : The common anchestor of the change. This is the BASE. RED : Your changes to the code. This is the REMOTE. ORANGE : The code change of someone else. This is the LOCAL. BLUE : The end result file after the merge. Here a more detailed illustration: Sometimes you will fallback to a two-way merge e.g. in cases where you or the other part deleted a file. Some tools refer them as "ours" or "theirs" ours => LOCAL theirs => REMOTE CONFISUNG NAMES? I personally find the naming confusing because why the h
Read more

Asynchronous Nunjucks with Filters and Extensions

Image
The Problem Nunjucks was developed synchronous. The architecture behind is synchronous. So if you use nunjucks everything is fine until you hit an asynchronous problem. One easy example is: You want to have a method to download a data as json from a server That is easy to solve, normally. You download the data before creating the nunjucks context and pass the data to nunjucks after download. The problem arises when you don't know the source of the data in front. An example: {% set dataSource = userSelection %} {% set data = loadData('https://mydomain/sources/' + dataSource + '.json') %} The userSelection is e.g. a value from a dropdown on an html page. This can have multiple values. Now you have to download the data while rendering the nunjucks template, because you don't know the value of the "dataSource" variable upfront. Nunjucks Filters Nunjucks Filters are making the language more flexibel. Filters are nothing else then a function. In Nunju
Read more

Debug Azure Function locally with https on a custom domain

Image
Description If you want to deploy an Azure Function normally this endpoint is publicly available. Therefore you need to secure the connection to this endpoint at least with ssl. Before you deploy you also want to test the connection probably locally. The following steps should help you to setup a https connection to a local Azure Function. 1 STEP: Create a Self Signed Certificate via PowerShell Open Windows Terminal or PowerShell as an Administrator The following script will create a self signed certificate in the "Users" own certificate store with the password 12345 The script will also export the certificate as PFX to C:\server.pfx The domain for the certificate will be "debug-local.com" $cert = New-SelfSignedCertificate -DnsName "debug-local.com", "debug-local.com" -CertStoreLocation "cert:\LocalMachine\My" $myPwd = ConvertTo-SecureString -String "12345" -Force -AsPlainText Get-ChildItem -Path "cert:\localMachine\My
Read more