Keeping your Drupal 8 modules, themes and custom code continually up to date, preparing for Drupal 9

Traditionally Drupal was developed in two parallel branches. Take the example of Drupal 7 and 8. There was the supported stable branch of Drupal 7 that received bugfixes only and there was a development branch of Drupal 8 where developers went free to change and improve things the way they have seen best. As the development of Drupal 8 was nearing release, contributed module and theme authors were asked to take a look and release new versions as well in preparation. While the new branch was built with great care, it was not proven yet in various production environments. It also often took quite some time for contributed modules and themes to update.

Drupal 7 to Drupal 8 API update
Traditional Drupal code vs. module compatibility

How to automate testing whether your Drupal 8 module is incompatible with Drupal 9?

Drupal 9 is planned to be only 18 months away now, wow! It is already being built in Drupal 8 by marking APIs to be removed in Drupal 9 as deprecated and eventually upgrading some dependency version requirements where needed. Once the Drupal 9 git branch will be open, you will be able to test directly against Drupal 9. That should not stop you from assessing the compatibility of your module with Drupal 9 now. To prepare for compatibility with Drupal 9, you need to keep up with deprecated functionality and watch out for upgraded dependencies (when we know which are those exactly). Of these two, automation can go a long way to help you keep up with deprecated APIs.

Diversity by example

(Disclaimer: Dries did not ask/order/suggest/request me to post this neither to make any changes whatsoever.)

I was reading Drupal Confessions with great interest, because my primary job for quite a while now is to help enable the best efforts in the Drupal community to work together to reach new heights. I am really privileged to be able to do this and make a living out of it, it is the job I always dreamed of. I also hope that I am being useful to the Drupal community in doing so. I kept nodding in agreement with the open letter's statements on diversity so I could not get rid of my cognitive dissonance on their connection with reality for several days now. The open letter says "We ask you to fight for us, Dries, to protect us from intolerance, harassment, smearing, bullying, and discrimination, no matter why or where it originates from."

As someone who is getting a paycheck at least indirectly from Dries in the past 10 years, and working as directly with him as possible in Acquia's Office of the CTO for the second half of that period, I have the opportunity to look at his practices in terms of diversity. Which would be the most observable group to learn more from if not his personal department where he directly appoints people?

In the past 5 years I've been closely working with Dries as a remote employee in the Office of the CTO at Acquia, which consisted of 15 people at most at any given time. In this time I worked with at least the following types of people directly in this group (in random order): blind, stutterer, person with ADHD, person with serious sleep problems, person with even more serious sleep problems, divorced, gay, bi, lesbian, asexual, polyamorous, gospel singer, BDSM, religiously raised, atheist, clinically infertile, cosplayer, very tall, short, people from Eastern Europe, Western Europe, US and India, native-borns, immigrants, people in offices, people always working remotely, capitalist, socialist, pacifist, people from a military family, adopting parent, transgender, people with tics, people who don't drink alcohol, etc. The teams I worked on usually had relatively high percentage of women in technical roles. My current team is 50% female, and 1/3rd of the department overall is female. This could not happen by accident.

While none of this represent the whole rainbow of humanity, and it could definitely be further improved, our limited group of 15 people already covered outstanding diversity in my view. Also this is a group that cares, we discuss and live through our struggles and support each other on every step where we can. I would challenge many of those signing the open letter to practice this kind of diversity in their teams. I for one really enjoy the varying values that people brought in and am sad that some of those great people have left to pursue other technical challenges.

In this five years, I never experienced that when hiring people either of these things were considered as a negative or that any person was treated or felt treated badly for any personal life matter. Neither that any of the amazing people who unfortunately left and are covered in the list left because of any of those.

Given that I just cannot get over my cognitive dissonance. Who are being convinced of what?

Improving Drupal 8's usability and the impact

We started regular Drupal usability meetings twice a week almost a year ago in March 2016. That is a long time and we succeeded in supporting many key initiatives in this time, including reviews on new media handling and library functionality, feedback on workflow user experience, outside-in editing and place block functionality. We helped set scope for the changes required to inline form errors on its way to stability. Those are all supporting existing teams working on their respective features where user interfaces are involved.

However, we also started to look at some Drupal components and whether we can gradually improve them. One of the biggest tasks we took on was redesigning the status page, where Drupal's system information is presented and errors and warnings are printed for site owners to resolve. While that looks like a huge monster issue, Roy Scholten in fact posted a breakdown of how the process itself went. If we were to start a fresh issue (which we should have), the process would be much easier to follow and would be more visible. The result is quite remarkable:

New status page in Drupal 8.3

Checking on Drupal 8's rapid innovation promises

Starting with Drupal 8, we decided to make more rapid innovation possible by releasing minor versions every 6 months that may come with new features and backwards compatible changes. Now that we released Drupal 8.1.0 and almost 8.2.0 as well, how did we do? Also what else is possible and what is blocking us to make those moves? What do all the changes mean for how might Drupal 9 unfold?

Dries Buytaert posted last Wednesday The transformation of Drupal 8 for continuous innovation and on the same day I presented Checking on Drupal 8's rapid innovation promises at DrupalCon Dublin. Here is a video recording of my session, which should be good for those looking to get to know Drupal's release process and schedule, as well as how we made it possible to experiment within Drupal core directly with Drupal 8. While I did hope for more discussion on the possibilities within Drupal 8 with the participants, somehow the discussion pretty much ended up focusing on Drupal 9, when it should be released and how much change should it come with.