Image courtesy- pxhere
Semver
Supply chain is a concept rooted in manufacturing world. It conceptualizes the chain of vendor, producer and consumer at the far end. As a seasoned developer you will have already noticed similarities to that in the industrial process of software development. Yes, software development these days is an industrial process. We also have a past where we tend to draw metaphors from the engineering (manufacturing) world particularly construction business isn’t it? No one organisation ever produces the entirety of software a consumer uses. This is a fact right from the time OS was distributed different from the computer. Think about it, in your organisation if you are developing web application; you will not write kernel of the OS or for that reason modify it, isn’t it? You depend on a vendor => OS supplier. That my dear reader is the first link in the supply chain. The link between OS supplier and yourself to deliver value to your customer. There are many fine lines which we have fliedover here. E.g., your organisation might not always deal with the OS supplier and put that as a pre-requisite for the customer themselves to deal. But we flied over such details to establish the fact that when you develop the software you need to consider such suppliers e.g., web server running on Windows OS has subtle difference to the web server running Linux. It is considerations like these that leads us to draw that metaphor of supply chain for software.
This is a boggling concept for any developer. Because, no more in the world of development you are alone. You are always prefixed and suffixed with other vendors. If you are pondering how does that matter to you. Think again!
Modern software development uses a concept of package manager. Pick your liking; npm, nuget, maven, cargo, pypi or anything else. Those are your interface to this supply chain. Let us rule out one thing before you run off in a tangent that is not healthy. These package managers do not enforce legal contract or buy you licences etc. They define which suppliers you work with and help you define your work product that you sell.
One element that underpins all these package managers and helps such tools deliver value is – Version. Yes, version of the binary (library or exe) of the dependent packages are very important element in the supply chain that has its tentacles laid on topics relating to licensing, security, business value (as newer versions are expected to deliver more business value) etc.
If you have developed software in a decade back or before that you might have been exposed versioning schemes that takes the shape like –
3.1 NT 3.1 1511 10586 20H2 1644160015.3182142
|
You might have connected with some and might not with others. But one thing that is common here is that there is no pattern. Absence of such pattern makes developing package manager and developing supply chain difficult.
Behold Semver; a simple and more importantly semantic versioning of software. Put simply, it is a versioning scheme that is declared to adhere to following pattern –
MAJOR.MINOR.PATCH-LABEL+META
|
That is the format which is great. Where is the semantics in that? If that is what you had asked here it is –
1. MAJOR must be incremented when one makes a breaking API change 2. MINOR must be incremented when new functionality is added with support for backward compatibility 3. PATCH must be incremented when bugs are fixed with backward compatibility 4. LABEL must be attached to version “-”character 5. META must be attached to version with “+” character
|
Both LABEL and META are optional and the only rule that they oblige to is content is dot separated. That is all! All that you needed to know about this Semver concept and amazingly the one that underpins the modern software development and distribution.
One of the practical problems that many libraries’ developers face is interpreting this Semver in code that they develop. In case you wonder, such necessities arise in scenarios like –
These are to name few but most common use cases when you will need to query the Semver. If you notice, these are necessities that arise on the consuming side of the Semver. i.e., once someone has defined the Semver you consume them and decided to something based on that information. We will pick this last thought in moments.
Luckily Semver protocol definition itself gives away a regular expression pattern (PCRE compatible regex parser) that can be used to extract the Semver information –
^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
|
This is great but you need to put this to use appropriately in your library development language be it javascript, C# or Python or anything else.
Scenarios like querying and finding with range requires additional logic which are abstracted in the format of numerous tools that are positioned adjacent to respective package managers.
npm has this cli tool called semver. You can install this from npmusing the command
npm install -g semver
|
This further gives you the ability to execute following commands form command prompt; particularly the interesting one’s are the range queries –
semver 1.2.8 -r ‘>=1.2.7 <1.3.0’
1.2.8
|
Here we just validated if the provided version is within the range of supplied range comparator string. Since, it is it fed back the number to us.
This library can be used in code i.e., within javascript as well. Thus, pushing us to use this check within code. The check above will become like this in the javascript –
const semver = require(‘semver’);
console.log(semver.satisfies(‘1.2.8’, ‘>=1.2.7 <1.3.0’));
|
This is great from consumption side. i.e., if we are consuming a library or some other process version to do something these libraries are great. What about the generation side? Remember Semver is a well-defined standard. Thus, will it not be possible to generate them for us? Then the question is when do we do that? We park that question for the next dispatch where put the supply chain perspective in more concrete manner and discuss about our options on the generation side. Remember, Semver is language independent and what we accomplished here is easily accomplished in other language that works with package manager. We kind these topics to conclude in our next dispatch.