Over the last few lessons,

we've gone through various aspects of creating components, configuring composer,

autoloading, some very basic unit tests and using accepted PSRs.

All this time we've not had a version number for

our code and all code needs a version number.

Composer enforces an established standard for

version numbering, which is called semantic versioning.

This is also known as SemVer.

SemVer enforces the structure of the version number, and

the level of the change allowed when incrementing these numbers.

Version numbers should have three parts.

The first is the major number.

The middle is the minor.

And the last is the patch.

Major is for making backwards incompatible changes.

These are also called breaking changes, because they'll break things for

developers for relying on your PHP API to be written in a certain way.

A breaking change could be renaming a class, moving a class into a different

name space, renaming a method, or even changing type pins for an argument.

Minor is making backwards compatible changes.

This could be adding new classes, methods, new arguments to methods,

basically anything that doesn't break the API.

Patch is for bug fixes, filling in security holes, and

potentially performance improvements if anything breaks out.

Patch should not be used to add new functionality as that forces developers to

pay far to much attention too the change logs.

When you are ready for

your first release, you might consider calling that version 1.0.

This is a bad idea, when your package is new,

your likely to discover a lot of improvements that involve changing things.

Your code will go marching through versions one, two, three,

four, far too quickly, and developers will get tired of constant major rewrites.

More commonly, developers version their initial release as 0.1.0.

This leading 0 tells developers that the previously mentioned rules of

SemVer are gonna be a little bit different.

The leading 0 means the package is in initial development.

And that means the API is not a 100% stable.

It will still never contain a breaking change in a patch release, but

it could break when a new minor version is released.

If a developer is relying on a component which starts with a zero,

they need to be super careful about upgrading if that middle number changes.

For example changing from 0.1.0 to 0.2.0 could cause logic errors or

even fatal errors.

SemVer can seem like a lot of rules to understand initially.

But it's so helpful for developers, regardless of the programming language to

subscribe to these same rules and expectations.

For us PHP developers, it means we can use Composer to install other

dependencies with very specific expectations.

Instead of requiring 1.5.0 than missing out on 1.5.1,

we can use a wild card to say 1.5.anything.

Next time you run an update, we'll have instantly installed a security update

knowing it won't break our applications.

If you have a get repository setup with Packagist, each time you tag a new

version and push that tag, you'll have released a brand new version on Packagist.

And the whole PHP community can instantly use your code.