In a few hours, Drupal 8 branches will be updated to begin using semantic versioning conventions. What are they? Why are they important? What does it mean to you? Let us talk about semantic versioning in general and with Drupal 8 in particular.
Semantic Versioning
It is not a totally new concept, but it is an old idea which everyone uses in parts or in one way or another. An old idea, with some rules, some conventions and a whole lot of standardization. I was going to write about this a long time back and how it applied to Drupal, in a way, but that never happened. The idea is now very mature (it’s into version 2.0.0 now) and Drupal 8 will begin with some ground work to start utilizing semantic versioning in a few hours (12 – 2 PM, New York time, 9:30 PM Indian Standard Time).
Drupal 8
This is just the first step and the event page on g.d.o explains the steps that will be taken. The benefits are numerous.
1. Clarity with version numbers
With semantic versioning, it becomes all the more clear of what you can expect to have changed, particularly if some of the changes are NOT backwards compatible. For instance, here is a snippet from the issue that discusses the implementation:
– Drupal 7.17 fixed some bugs, added new features, added new hooks, and more.
– 7.18, 7.19, and 7.20 were security only fixes.
– 7.21 fixed a regression introduced by 7.20, but was not itself a security fix.
– 7.22 fixed and added a bunch of stuff, including a BC break.
It is hard to say, just from the version number, that there was a break in backward compatibility. There are also releases with new features, and then security fixes, and then again regressions in other releases. With semantic versioning, new features the above would have played something like this:
- Drupal 7.1.0 added new features, added new hooks, and more (but none breaking backward compatibility).
- Drupal 7.1.1, 7.1.2, and 7.1.3 were security only fixes. These fixes could also go into 7.0.x stream as 7.0.1, 7.0.2, 7.0.3.
- Depending on how the regression, played out, there would fixes to 7.1.4 and/or 7.0.4.
- A backward compatibility break would have to go to 8.0.0.
Now, just by looking at the numbers, it is much more easier to say what has changed where.
2. Easier to get fixes without new features
If you are worried about putting in new features but are anxious to get all the bug-fixes in your tried and tested application, you would have to track bug-fix patches with every new release and apply them yourself. Not only this is tedious and complex, but disastrous if it goes wrong and impossible to maintain indefinitely. You would only pile up cost of testing until you have to bite the bullet and actually upgrade to a new release.
Now, with semantic versioning, just stay in the same MINOR version as before and keep using the releases as they come out. Carrying in from previous example, if you don’t care about new features in 7.1.0, just stick to the 7.0.x scheme and still get all the bugfixes as they come out.
3. Faster innovation
Currently, big features are only slated to come out when the next big Drupal version comes out, which averages to at least 3 years. This actually discouraged contributions by organizations as any contribution would come to fruit only once the new version comes out. We are already touching close to four years since Drupal 7 was launched and not even in Drupal 8 beta cycle, and all the work going in Drupal 8 isn’t being used.
This changes. The plan is to release the next version with new features every six months (only features which do not break backwards compatibility). This means that within six months of Drupal 8.0.0, there will be a Drupal 8.1.0 with new features. This encourages more contributions, keeps people excited and things fresh. Win-win all around.
4. Dependency management
As a benefit of semantic versioning, managing dependencies between required Drupal core and modules gets a whole lot simpler. Components could point to the exact minor version (features) they need to work and stay compatible when new minor releases come out. This is one of the biggest weaknesses of Drupal – that all modules stop working when you upgrade Drupal to bring in new features. This will still happen for major versions, i.e. between Drupal 8 and Drupal 9, but not between Drupal 8.0 and Drupal 8.1, where there could still be considerable amount of new features.
5. Managing bug-fixes
Currently, we worry about backporting bug-fixes to the latest supported minor release. With semantic versioning, another option to manage this is to first fix the bug in the earliest supported minor release and bring it forward to others. Bringing it forward this way could be done by a simple merge.
What does it mean?
The proposal discusses what benefits open up for Drupal 8 at length. Most of the benefits listed above apply to all projects using semantic versioning (that is what is so great about standards), whereas, with some additional policies, Drupal releases are kept predictable and easy to manage (see the section “How to balance these audiences’ needs?” in the proposal).
We’ll see what changes come up in due course. Today, all it does is that whatever applied to 8.x now applies to 8.0.x. Any new features don’t have to be postponed to 9.x, but given the feasibility, they would get postponed to 8.1.x. As a module developer, you should be able to require the specific minor version that you require (at least).
Finally, as a developer, you will be expected to deal with one less Drupalism and embrace modern, sophisticated release management techniques; and that is as big a step as any as you would take.
What do you think of the move to semantic versioning? Notice an error in what I wrote? Do let me know in comments below and please share this article.
Image Credit: drupal.org