Drupal core dev cycle

The legend

Drupal core dev cycle

• Release Drupal X
• Profit!!1!
• Free-reign on Drupal X+1

We have to allow ourselves to break APIs in order to innovate.

Drupal core dev cycle

• API freeze slush yogurt?
• "Just fix the bugs"
• ...
• Release!

GOTO 1

Drupal core dev cycle

The reality

Drupal core dev cycle

• Release Drupal X
• Catch up on sleep
• Ignore Drupal X
• Do stuff we forgot about
• Design new stuff (Have we even used the old stuff yet?)
• Panic because we have no clue how long we have

Drupal core dev cycle

Eventually...

• Dries announces feature freeze
• Panic some more
• Freeze Slush Smoothy
• Many wander off... Only the stubborn remain
• Stumble into Y.0 in comotose stupor
• Release!

Why Panic?

I think I am burned out, I am literally losing sleep over this, but I am too stubborn to care about my own feelings because I know I will have to live with this for the next three years.

— Kris Vanderwater (EclipseGc)

Corporate interest

We love long release cycles! Yay stability!

We won't contribute to long release cycles. ROI takes too long.

Sometimes API breaks are necessary in order to evolve.

If you cannot innovate without breaking APIs,
you don't have an API.

Drupal 8 was necessary... but should be rare.

What Drupal needs

• More stability (but not less development)
• Rapid iterative development
• Shorter ROI

How do we get that?

• Loosely-coupled components
• Separation of concerns
• Clear API boundaries
• Swappable components by design

Clear interfaces and real APIs

All of those changes we've been making for the last 2 years

• Dependency injection
• Interface-driven development
• \Drupal\Component

Drupal 8 makes this possible

How's that work?

Rename classes/interfaces

class BookManager {
  public function getAllBooks() {}
}
class BookRepository extends BookManager {
  public function doSomethingNew() {}
}

function core_cool_stuff(BookRepository $repository) {
  $books = $repository->getAllBooks();
  $repository->doSomethingNew();
}
function contrib_cool_stuff(BookManager $manager) {
  $books = $manager->getAllBooks();
}

Future-looking interfaces

interface OldStyleInterface {
  public function foo();
}
interface NewStyleInterface extends OldStyleInterface {
  public function bar();
}

function cool_stuff(OldStyleInterface $service) {
  if ($service instanceof NewStyleInterface) {
    $bar = $service->bar();
  }
  else {
    $bar = "Some previously assumed value.";
  }
  // ...
}

Service-swapping

That's the whole point of interfaces and Dependency Injection

Just add stuff

• REST UI
• Improved REST link support
• Improved REST XML support
• Improved REST link documentation
• More pre-canned profiles (Snowman)
• Improve taxonomy admin pager (and other admin UIs)
• Continue to refine Seven style guide
• Cache improvements
• "_page" unified controllers
• HookEvent bridge
• All kinds of stuff!

Druplicon: API?

WRONG!

(This is why we can't have nice things.)

The proposal

• Do not open Drupal 9 dev for at least a year
• Add significant non-breaking features to Drupal 8
• Force ourselves to think about BC
• Track desired BC-breaks
• Drupal 9.0: Just the BC changes

This will be a hard learning experience

But it's how we have our (cup)cake and eat it to

Possible schedule

• January: 8.0
• February: 8.0.1 (bugfix)
• March: 8.0.2 (bugfix)
• April: 8.1.0 (features)
• May: 8.1.1 (bugfix)
• June: 8.2.1 (bugfix)
• July: 8.2.0 (features)
• etc.

Potential problems

• But how can we innovate?
  The same way as everyone else
• But we don't even know if our new APIs will stand up to it!
  Let's find out!
• But that pushes D9 even further away!
  Or shorter dev. Won't feel it if we get new toys.
• But our packaging scripts aren't up to the task.
  DA, this is your job.
• But what about translations?
  localize.drupal.org; string changes OK with warning.
• But I like my playground!
  $100 million ride on this. Take it seriously.

Security releases

• After 8.1.0, do we still provide 8.0.z security patches?
• What becomes the LTS release?
• Do we expect people to update to "feature" releases?
• The Security team is too busy as is... (needs resourcing)

This is the only hard problem. It's solvable.

What we get

• faster improvements
• Lower stress (New features are only a few months away.)
• Easier corporate investment
• Easier small-shop investment
• Important learning experience
• Good PR
• We know what is actually needed in Drupal 9

To prepare

• Decide what is an "API". Interfaces only? FAPI?
• Denote what is an API break. @api, @deprecated
• Ensure solid interfaces/swappability
• Get Drupal.org up to the task