Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
Composer supports the Semantic Versioning by default, and developers should follow the rules so that everyone knows what to expect from updates.
-
0:00
Over the last few lessons,
-
0:01
we've gone through various aspects of creating components, configuring composer,
-
0:05
autoloading, some very basic unit tests and using accepted PSRs.
-
0:10
All this time we've not had a version number for
-
0:11
our code and all code needs a version number.
-
0:14
Composer enforces an established standard for
-
0:16
version numbering, which is called semantic versioning.
-
0:19
This is also known as SemVer.
-
0:20
SemVer enforces the structure of the version number, and
-
0:24
the level of the change allowed when incrementing these numbers.
-
0:28
Version numbers should have three parts.
-
0:30
The first is the major number.
-
0:31
The middle is the minor.
-
0:33
And the last is the patch.
-
0:35
Major is for making backwards incompatible changes.
-
0:38
These are also called breaking changes, because they'll break things for
-
0:41
developers for relying on your PHP API to be written in a certain way.
-
0:45
A breaking change could be renaming a class, moving a class into a different
-
0:48
name space, renaming a method, or even changing type pins for an argument.
-
0:53
Minor is making backwards compatible changes.
-
0:56
This could be adding new classes, methods, new arguments to methods,
-
0:59
basically anything that doesn't break the API.
-
1:02
Patch is for bug fixes, filling in security holes, and
-
1:05
potentially performance improvements if anything breaks out.
-
1:08
Patch should not be used to add new functionality as that forces developers to
-
1:11
pay far to much attention too the change logs.
-
1:15
When you are ready for
-
1:15
your first release, you might consider calling that version 1.0.
-
1:19
This is a bad idea, when your package is new,
-
1:22
your likely to discover a lot of improvements that involve changing things.
-
1:25
Your code will go marching through versions one, two, three,
-
1:28
four, far too quickly, and developers will get tired of constant major rewrites.
-
1:32
More commonly, developers version their initial release as 0.1.0.
-
1:37
This leading 0 tells developers that the previously mentioned rules of
-
1:40
SemVer are gonna be a little bit different.
-
1:43
The leading 0 means the package is in initial development.
-
1:46
And that means the API is not a 100% stable.
-
1:49
It will still never contain a breaking change in a patch release, but
-
1:51
it could break when a new minor version is released.
-
1:55
If a developer is relying on a component which starts with a zero,
-
1:57
they need to be super careful about upgrading if that middle number changes.
-
2:01
For example changing from 0.1.0 to 0.2.0 could cause logic errors or
-
2:07
even fatal errors.
-
2:09
SemVer can seem like a lot of rules to understand initially.
-
2:12
But it's so helpful for developers, regardless of the programming language to
-
2:15
subscribe to these same rules and expectations.
-
2:18
For us PHP developers, it means we can use Composer to install other
-
2:21
dependencies with very specific expectations.
-
2:24
Instead of requiring 1.5.0 than missing out on 1.5.1,
-
2:28
we can use a wild card to say 1.5.anything.
-
2:32
Next time you run an update, we'll have instantly installed a security update
-
2:36
knowing it won't break our applications.
-
2:38
If you have a get repository setup with Packagist, each time you tag a new
-
2:42
version and push that tag, you'll have released a brand new version on Packagist.
-
2:45
And the whole PHP community can instantly use your code.
You need to sign up for Treehouse in order to download course files.
Sign up