Semantic Versioning – why you should care

Semantic Versioning – why you should care” is a nice take on Semantic Versioning and how and why people should is. I particularly liked the practical examples of changes and which version bump they correspond to.

I frequently find myself explaining the Semantic Versioning to developers, and going over some example changes. Now I can just send the link to that article instead and safe myself some time.

Very nicely done!

PHP : Composer Galaxy

PHP has one of the greatest, in my opinion, dependency managers – Composer. The tool works mostly with the public projects via the Packagist website (although it also supports private repositories).

There are over 200,000 packages available on the Packagist to choose from. However, the stats could be a lot better.

Today I came across a mind-blowing visualization of the composer packages and the dependencies between them. Have a look at Code Galaxies Visualization. You can find specific packages via the search, or interactively navigate the star map, like you are in the spaceship.

Stunning!

Our Software Dependency Problem

Our Software Dependency Problem” is a great article going in-depth into the subject of the dependency management during software engineering.

Dependency managers have scaled this open-source code reuse model down: now, developers can share code at the granularity of individual functions of tens of lines. This is a major technical accomplishment. There are myriad available packages, and writing code can involve such a large number of them, but the commercial, legal, and reputational support mechanisms for trusting the code have not carried over. We are trusting more code with less justification for doing so.

Not only it nicely describes the problem in simple terms, but also provides practical examples and solutions to it. In particular, I enjoyed the section that suggests how to improve dependency evaluation in terms of design, code quality, testing, debugging, maintenance, usage, security, and licensing.

Show outdated composer packages


A while back I shared a way to show outdated composer packages.  Today, I want to expand on it a little bit.  Thanks to this tweet:

I think it’s slightly easy to remember with “composer show -molD -strict” (“old”, “mold”).  Adding this to the test suite is a great tip too!

For other ways to show the outdated packages (using composer plugins), have a look at this StackOverflow thread.

Semantic Versioning : Version 0 is unstable


We’ve been using Semantic Versioning for quite a while at work now.  It’s easy to explain and follow, and it provides valuable context to the numerous releases of the projects and components that we are doing on a daily basis.

Turns out, however, that I missed a small, but important part of the standard.  All releases in major version 0 are considered to be unstable, so even if they introduce backward compatibility breaking changes, there is no need to increment the major version to 1.  Here’s the relevant quote:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

If you are relying on the semantic versioning in your projects, make sure to check your dependency management tool, to verify that it handles major version 0 correctly.  Gladly, for us, composer does the job:

The ^ operator behaves very similarly but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.