A release plan for contributed drupal extensions

Planet Drupal - 25. Oktober 2017 - 3:51

tl;dr: Review the plan at the end directly.

Software has a changing nature; Drupal and its extensions are not the exception.
To be useful for a most of the users, those need to be on full releases, not only on the version control system; indeed the problem is not new and there is even a well-known phrase for one of its solutions: release early, release often
Therefore it is important to have a release plan.
Following after some context and reasoning, I propose a couple of practical guidelines on release schedule for contributed drupal extensions that I intend to use: release weekly until stable, then once a month following core shedule.

On the changing nature of software

Software inherently tends to change, there are exceptions like embedded systems or really purpose-specific software.
Even really solid software like GNU core utils project, started on 1992, which provides tools that I consider among the most mature in the software space used daily, has 253 commits and three point releases in the last 12 months[1].

How much a software change depends on many factors.
I would hypothesize that the most relevant factors are the age of the project, the environment around it, and the amount of people behind it.
In this way, new projects change more than well established projects, and projects around dynamic environments which is also influenced by the amount of people around it, will also change more than the ones in environments with less participants or less technology changes.

How changing are contributed drupal extensions?

Drupal contributed extensions are naturally mainly influenced by drupal core, so let us examine a bit how changing is Drupal core.
It is definitely on a dynamic environment, and I will argue that each major release can be considered a new project, making it really changing.

On the dynamic side, even if web standards changes slowly, and for good reasons, technologies around web tools are still constantly changing.
The stack has changed a lot over the years, and even if some tools like apache and mysql/mariadb are still around, other parts of the stack has been changing a lot, especially around client side javascript.

Drupal core project code history is now 17 years old, which seems like enough time to get into a stable state, especially if you are not yet part of the drupal community.
But the drupal project has a history on rewriting the way its internal works, which has been argued as one of the reasons why drupal can keep up with the changing environment around web technologies.
It may be also a consequence of its amazingly collaborative community.
And because of this rewriting between major versions, at least internally, each major release can be considered a new project, especially with 8.x.x.
A hint about it may be reflected in the fact that major contributors across different drupal core versions are mainly different; only a few one are as active across releases.

In consequence, drupal core is still a highly changing project, and in the same way its extensions inherit part of that changing nature; but a contributed drupal extension is not really only influenced by core.
Given the amazingly high number of written extensions, it is only natural to start depending on other software pieces and make its maintenance more effective.
For instance, currently there are 13432 and 4069, D7 and D8 compatible modules respectively.

In this way, one of the factors that will clearly influence a contributed extension is their dependencies, both inside and outside the drupal, and how changing they are.

Another factor is the amount of people behind it, not only developers, but also users reporting bugs.
For drupal contributed extensions this vary a lot, but it is usually not that big.

For all this, contributed drupal extensions are usually in a changing environment.

Commits are not releases: release early, release often

As a contributed module developer myself, I will start by mea culpa.
Sometimes I wrongly assume that when a change is inside git the work is done, but that may be only true for people willing to take the extra effort to get the changes from git, or assume the consecuences of using a development release.
Commits are a developer tool inside the used version control system, but not necessarily something that is visible/usable for all.

As in many occasions, the problem is not new, and I find a pretty good answer for it on "The Cathedral and the Bazaar" chapter 2: Release early, release often.
It mainly propose that to be able to tackle enough bugs to make the software usable, the amount of releases needs to be as fast as the pace of the development, even at the cost of some stability.
I definitely recommend reading it fully for more context, and a lot more inspiring insights for any open source developer.

How often is often? A release strategy plan

Granted, the answer is not a recipe, and it makes sense it is that way because it really depends on the project.
On the following lines I will propose an specific release strategy for drupal contributed extensions.

Drupal core already has a release plan, it is really detailed, so please review it if you have not done it yet.
Minor releases are approximately available every six months, but security and bugfix releases for a given minor version branch are available monthly, on third and first Wednesday respectively.

Security releases for drupal contributed extensions are published in coordination with the security team, so there is no need to plan them here, they also happen on Wednesdays.

Making it simple to remember can help maintainers stick to it, so I will also be using Wednesdays as well as the weekday for releases.

The plan

I propose the following for each supported major branch in contributed extensions:

  • release alpha/beta/rc weekly on Wednesdays, until a stable is ready
  • release bugfix releases once stable has been reached in the same schedule than core, i.e. the first Wednesday of the month;

Looking back, it seems obvious and really simple, but if it is not documented somewhere, I will probably forget about it.
Hopefully someone else finds this useful, or even better wants to do the same.
Having a more predictable schedule always help to make better planning decisions.

I will start this week using this two guidelines and release a new version in the modules I maintain and there are pending changes to be released.

Auto-notify maintainers

Notifications may help us maintainers to stick to this, but I guess the plan itself was relevant enough keep the focus of this post.
I may be exploring some solutions around it in the future.

[1] To reproduce statistics you can retrieve the main repository from and then run a couple of commands:
git log --oneline --all --since="1 year ago" | wc -l git log --oneline --all --since="1 year ago" --decorate | grep tag

Etiquetas: Blog: AGILEDROP: First days on board with A-team

Planet Drupal - 25. Oktober 2017 - 3:05
When new developers arrive in our team, our mission is to help them as much as we can in every aspect of adaption to the new job environment, so they can show their potential and shine in their best light. First days at a new job are really important. Based on first impressions developers form the picture about their new coworkers and about the company itself, and that can have an impact on long-term. We pay great attention to the first days with us, so we prepared a brief insight in first work days at our company. First day We show the new developer around, show the desk and her… READ MORE Blog: AGILEDROP: Why should agencies partner with companies rather than hire freelancers?

Planet Drupal - 25. Oktober 2017 - 1:38
Digital agencies sometimes get in a position when they have more work their internal team can handle. For many outsourcing is not an option, as they still wish to keep the project in the house, but are open to working with external developers. Agencies can hire freelancers or work with teams like AGILEDROP. In this post, I will highlight some of the advantages of working with a team that agencies often overlooked when making a decision. No more job posts and screening interviews Hiring a freelancer is practically the same as hiring a full-time employee. First you have to write a job ad and… READ MORE

Umfrage zu Elektroautos: 5 Prozent erwägen Kauf eines E-Autos

heise online Newsticker - 24. Oktober 2017 - 19:00
Als nächstes Auto kommt für 5 Prozent der Teilnehmer einer Umfrage ein rein elektrisch betriebenes in Frage. Wichtig für die Kaufentscheidung ist vor allem der Anschaffungspreis und die Reichweite.

Manifesto: City of Drupal: thoughts on DrupalCon Vienna 2017

Planet Drupal - 24. Oktober 2017 - 18:51
It seems like a long time ago now… Well. It was…. At the time of writing, it’s three weeks since I was at DrupalCon. I could argue I’ve been taking time for reflection, but actually we’ve been super busy and so I’m just getting round to penning my thoughts and memories of my week in. Continue reading...

Sexuelle Übergriffe: Frauen beschuldigen einflussreichen US-Technikblogger Robert Scoble

heise online Newsticker - 24. Oktober 2017 - 18:30
Die US-Journalistin Quinn Norton schildert sexuelle Übergriffe der amerikanischen Technikblogger-Größe Robert Scoble, woraufhin sich weitere Betroffene melden.

Softwarechef: Kein weiteres Apple-Event im Oktober

heise online Newsticker - 24. Oktober 2017 - 18:30
Craig Federighi zufolge wird es wohl keine zweite Keynote im Herbst geben. Offenbar kommen HomePod und iMac Pro ohne eigene Veranstaltung auf den Markt.

Hackerangriff: Russische Nachrichtenagentur Interfax wohl von Kryptotrojaner getroffen

heise online Newsticker - 24. Oktober 2017 - 18:00
Die russische Nachrichtenagentur Interfax ist am Dienstag durch einen Hackerangriff lahmgelegt worden. Fast alle Server seien betroffen, sagte der stellvertretende Generaldirektor Alexej Gorschkow. Es sei unklar, wann das Problem behoben werden könne.

Ausstellung "Open Codes" im ZKM: Coding zum Anschauen und Mitmachen

heise online Newsticker - 24. Oktober 2017 - 18:00
Co-Workings Spaces, Exponate zur Digitalisierung, Free Drinks, Snacks und freier Eintritt: Das ZKM in Karlsruhe will mit dem Ausstellungsprojekt "Open Codes" das Museum neu erfinden.

Visionen für die Zukunft auf der push|con

heise online Newsticker - 24. Oktober 2017 - 18:00
Die Zukunft selbst gestalten, das wollen die Referenten und Teilnehmer der push|con. Das Event versammelt vom 25. bis 27. Oktober in Ahaus Innovationsbegeisterte zu Themen wie Elektromobilität, Digital Living, Finetrading und Virtual Reality.

iOS 11: Taschenrechner scheitert an Grundrechenarten

heise online Newsticker - 24. Oktober 2017 - 17:30
Apple hat in seinem neuen Mobilbetriebssystem die Calculator-App umgestaltet. Nutzern ist nun aufgefallen, dass sie aktuell wenig zuverlässig ist – selbst bei Grundrechenarten.

Delta: Fluglinie wechselt angeblich von Microsoft zu Apple

heise online Newsticker - 24. Oktober 2017 - 17:30
Statt mit Surface-Tablets und Lumia-Smartphones sollen die Crews der US-Airline künftig mit iPads und iPhones ausgestattet werden, heißt es in einem Bericht.

Drupal Modules: The One Percent: Drupal Modules: The One Percent —Create user permission (video tutorial)

Planet Drupal - 24. Oktober 2017 - 17:29
Drupal Modules: The One Percent —Create user permission (video tutorial) NonProfit Tue, 10/24/2017 - 10:29 Episode 41

Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Create user permission, a module which allows users to create other users without granting all the permissions administer users provides.

Blair Wadman: Override Drupal 7’s page template for a content type

Planet Drupal - 24. Oktober 2017 - 17:06

Creating a page template for a content type gives you a lot of control over the structure of the page. While Drupal will automatically pick up a node template for a content type, if you use the right naming convention, it will not for a page template. Fortunately it just takes a few lines of code and you can create a page template for any content type you choose.

Kartellverdacht: BMW ist sauer auf VW und Daimler

heise online Newsticker - 24. Oktober 2017 - 17:00
Der bayerische Autohersteller kritisiert Konkurrenten, weil sie als Kronzeugen in den Untersuchungen um einen Kartellverdacht auftreten wollen.

Mac-Shareware-Downloads mit signiertem Trojaner

heise online Newsticker - 24. Oktober 2017 - 17:00
Die Apps Folx und Elmedia Player wurden nach einem Hack über deren Websites inklusive der "Proton"-Malware vertrieben. Der Hersteller empfiehlt eine Neuinstallation betroffener Maschinen.

Mozilla will die Mixed-Reality-Entwicklung nach vorne bringen

heise online Newsticker - 24. Oktober 2017 - 17:00
Nachdem Mozilla 2017 hauptsächlich Virtual-Reality-Konzepte unterstützt hat, will die Non-Profit-Organisation nun die Entwicklung von Mixed-Reality-Konzepten mit einem dezidierten Programm fördern.

KI-Konferenz: CfP der Minds Mastering Machines um eine Woche verlängert

heise online Newsticker - 24. Oktober 2017 - 16:30
Bis zum 29. Oktober haben Experten nun Zeit, sich mit Vorträgen zu Themen rund um Künstliche Intelligenz und Machine Learning zu bewerben. Die Fachkonferenz richtet sich in erster Linie an Entwickler, Data Scientists und Forscher.

Medientage-Chef: Rundfunkbeitrag auch für private Anbieter öffnen

heise online Newsticker - 24. Oktober 2017 - 16:30
Sieben der zehn erfolgreichsten Facebook-Posts über Angela Merkel sind laut einer Studie Fake-News. Welchen Nachrichten ist noch zu vertrauen? Die Medientage München sollen eine Antwort geben. Aber auch ein typisch deutsches Thema kommt dort zur Sprache.

Deeson: Deeson at DrupalCon Vienna 2017: Excellence in the tech team

Planet Drupal - 24. Oktober 2017 - 15:43

In my previous post I shared key takeaways from a Birds of a Feather (BoF) session I ran at DrupalCon Vienna last month on what it means to be an Agile agency

Another BoF session I ran invited conference attendees to share their experiences of managing team members and ensuring technical excellence. We covered each topic in a lot of depth, and at times it felt a bit like a counselling session for new and aspiring tech leads!

Here’s a snapshot of what we discussed:

Overcoming resistance to change.

The group debated how best to roll out changes within the tech team, such as changing version control software to git. Tech leads don’t always feel empowered to force through new initiatives, and can get frustrated by developers who either don’t want to change or are unable to see the benefits.

We spoke about the need to introduce change gradually and gain buy in through mechanisms such as team meetings, highlighting the importance of allowing changes to be discussed and concerns to be heard.

It can be helpful to identify evangelists in the team who will promote the change, and can act as support contacts during the period of transition so that no one suffers in silence.

Leading change in remote teams.

Change is hard enough when you’re all in the office together – how do you ensure a smooth transition in co-located and distributed teams?

At Deeson, we’ve introduced a quarterly get together in person. We set up the changes the tech chapter plans to make over the next quarter, and assign owners to develop the ideas and facilitate the transition process.

We also run group workshops on the changes made during the last quarter, allowing people to gain hands on experience with a new tool or technique under the supervision of those that specified it and their evangelists. This allows us to identify any problems and concerns before the change is mandated.

Dealing with complaints.

It’s natural and healthy to express concerns or frustrations. But what do you do when a team member seems to complain more than most? 

As a manager you feel responsible for solving every issue that arises, and of course there are times when the onus will rightly fall on you.

However, in the case of a chronic complainer it can be more effective for you as tech lead to listen to the grievance and empower the person to consider their options and suggest solutions, rather than exhaust yourself trying to solve the issue on their behalf.

Transitioning to tech lead.

Often a developer progresses until they one day find themselves leading a tech team, without ever having received any formal leadership or management training. We spoke about the changes you need to make, and how to understand what’s expected of you in your new role.

We cited the book The Manager’s Path by tech lead turned CTO Camille Fournier as an excellent reference. The Lead Developer conference which takes place annually in London is another good resource. Talks are made available online and provide a lot of guidance to those new to the tech leadership position.

Here’s one of our favourites:

Want to work with the largest Acquia Certified team in Europe and one of the top 30 companies contributing to Drupal globally? We’re hiring.