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