Semantic Versioning2:49 with Phil Sturgeon
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