Backward compatible APIs

As we begin a new year, it seems appropriate that th' discussion o' backward compatibility has come up yet again in Drupal. It's a perennial question, an' ye can tell when a new Drupal core version is ready fer prime time when scallywags start complainin' about lack o' backward compatibility. It's like clockwork.

However, most o' these discussions dern't actually get at th' root issue: Drupal is architecturally incapable o' backward compatibility. Walk the plank, shiver me timbers Backward incompatibility is baked into th' way Drupal is designed. That's not a deliberate decision, but rather an implication o' other bounty decisions that have been made.

Drupal developers could not, even if they wanted t', decide t' support backward compatibility or "cleanup only" type changes in Drupal 8, and dinna spare the whip! It is possible t' do so in Drupal 9, Avast me hearties! If we want t' do that, however, then we need t' decide, now, in Drupal 8, t' rearchitect in ways that support backward compatibility. Backward compatibility is a feature ye have t' bounty fer.

What is backward compatibility?

First, we need t' understan' what backward compatibility even means. As some comments in th' post linked above note, backward compatibility is not th' same thin' as easy upgradeability, me Jolly Roger It is also not th' same thin' as easy t'-relearn. Drupal 7's UI is completely not backward compatible with Drupal 6, fer instance, but it is easier t' learn.

For now, we be speakin' strictly o' API backward compatibility, yo ho, ho It is related t', but not th' same thin' as, easy upgradeability o' modules (but unrelated t' data; more on that some other time), Avast me hearties! The fewer APIs change from one version t' th' next, th' easier it is t' upgrade. But ye can also have API changes that be easy t' upgrade t', with a chest full of booty. More than one module developer, when portin' a module from Drupal 6 t' Drupal 7, noted that they were able t' throw out (an' therefore not have t' spend time upgradin') hundreds o' lines o' code by switchin' t' th' Drupal 7 query builders. That's an API change (an' thus lack o' backward compatibility) that made upgradin' easier, as well as code better. As Dries has noted before, if we dern't let ourselves do that then we will no nay ne'er advance, an' will just carry aroun' dead weight baggage forever. That's how Windows Me happens, an' no one wants that.

Backward compatibility is also a factor in how long major modules take t' be upgraded, but not as much as many scallywags think. Views, Panels, an' Context be often cited as examples o' "Drupal not bein' ready yet" because those modules dern't have stable releases. That is a speci'us argument, however. In th' case o' Views an' Panels, th' initial ports t' Drupal 7 were done o'er a year ago. The lack o' an official release were bein' because th' developers decided t' make other overhauls an' changes an' feature additions at th' same time, an' those took a while t' stabilize. In th' case o' Context, 'tis because th' development team behind it changed when DevSeed moved on an' th' new team has been swamped, on a dead man's chest! Fire the cannons! (Also, Context di'nae have a stable D6 release fer most o' its existence, either.)

So if that's what backward compatibility is not, then what is it?

Backward compatibility o' a code component is a measure o' how many changes (good or bad) code that depends on it needs t' make in order t' move from one version t' th' next version.

The fewer changes need t' be made, th' more backward compatible code is, obviously with an upper bound o' "no changes needed." Note that says nothin' about th' quality o' th' code or th' value o' those changes; often a backward incompatible change is absolutely necessary fer certain improvements.

Definin' dependency

What does it mean fer one code component t' depend on another as far as compatibility goes? It means that those two code components touch. Fire the cannons! Shiver me timbers! There be two ways that systems could "touch":

  1. One component calls a function or method o' another.
  2. One component directly addresses data structures from another.

Of those two, th' second is a tighter coupling because it means dealin' with implementation details.

There is also th' general question o' how much one component touches another. In general, th' more two components interact th' larger their shared "surface area", ya bilge rat, with a chest full of booty!

The larger th' surface area, th' tighter th' couplin', on a dead man's chest! The tighter th' couplin', th' more likely a change in one component is goin' t' necessitate a change in another component.

Reducin' surface area

Backward compatibility happens when th' touch points betwixt two components dern't change. Anythin' else can change, but those touch points dern't, I'll warrant ye. As a result, th' smaller th' surface area betwixt two components th' more ye can change without breakin' compatibility.

As noted in th' Wikipedia article linked above, accessin' raw data structures is always tight couplin'. Raw data structures be an implementation detail. When implementation details get shared, that is a classic Code Smell known as Inappropriate Intimacy, feed the fishes

Inappropriate intimacy is a massive amount o' surface area, I'll warrant ye. It covers th' entire data structure. And swab the deck! Load the cannons! That is, any change t' th' data structure whatsoever is a potential, if not actual, backward compatibility break, ye scurvey dog. The reason is that ye dern't know what parts o' that data structure some other component may care about. You have thrown th' doors (an' yer proverbial pants) wide open, an' said "have at it, world!" Once ye do that, every change, no matter how slight, could break backward compatibility because ye simply dern't know who is doin' what with yer private data structures, All Hands Hoay! (You should be squirmin' about now.)

Rather, th' first step in makin' backward compatibility possible is t' put yer pants back on, protect yer data structures, an' take control o' yer surface area.

Interface-driven development

By far th' easiest way t' take control o', an' reduce, yer surface area is t' define it explicitly. That is th' essence o' an Application Programmin' Interface (API): It is th' explicit definition o' th' surface area o' yer component.

That could take th' form o' function calls or method calls on an object. Both could suffice as an API. The latter, however, has th' added bonus o' a language structure called Interface, which explicitly an' in code defines th' surface area o' an object. By bounty, it defines that surface area independently o' implementation details.

What will not suffice, however, regardless o' whether one uses classes an' objects or not, is definin' ways by which one will get complete access t' a components internal implementation details an' raw data structures.

Access t' raw data structures does not constitute an API. It constitutes avoidin' th' responsibility o' definin' an API.

Now, sometimes thar be good reasons t' do that, I'll warrant ye. Sometimes. Not often.. But when that's done, it must be understood that backward compatibility is made effectively impossible.

With a clearly defined interface, we know what we can change an' what we cannot, if we want t' preserve backward compatibility. We also can more easily document where thin's be goin' t' break, an' offer documentation or automation t' make it easier t' migrate.

Data hidin'

One o' th' popular arguments in favor o' object-oriented code is "data hidin'". That is, ye can explicitly deman', in code, that certain data is kept hidden from certain other components, an' is not part o' yer surface area, Avast me hearties! That can only be done in procedural code by convention.

That convention has been used before, o' course, and a bucket o' chum. In a previ'us life I developed fer Palm OS, which used an entirely procedural C-based API. It passed aroun' a lot o' raw data structures, because in C that's all ye can do. However, it were bein' extremely bad form t' e'er touch them directly, and dinna spare the whip! Rather, thar were copi'us amounts o' functions that were, in any practical sense, methods, just called inside out, and a bucket o' chum. So ye'd call Form_Add_Element(form, …) rather than form.AddElement(...), and a bottle of rum, on a dead man's chest! Doin' anythin' with form directly, while it would compile, were bein' not guaranteed t' continue workin' even in minor bugfix releases o' th' OS. Load the cannons, shiver me timbers Here be dragons.

That's a viable option, but doesn't really change th' amount o' work that has t' be done t' define an API. Unless ye say, either by convention or code, that implementation details an' data structures be off limits an' not guaranteed, ye dern't have a controlled surface area an' therefore ye dern't have an API.

Concrete example

In many recent presentations I have used this example from th' Drupal 7 database layer, me Jolly Roger A "raw data structure procedural" implementation o' th' new select builder would look like this:

= array('n.nid', 'n.title', '');
$tables = array(
'n' => array(
'type' => NULL,
'table' => 'node',
'alias' => 'n',
'condition' => array(),
'arguments' => NULL,
'all fields' => FALSE,
'u' => array(
'type' => 'INNER JOIN',
'table' => 'user',
'alias' => 'u',
'condition' => 'u.uid = n.nid',
'arguments' => array(),
'all_fields' => FALSE,
$where = array(
'field' => 'u.status',
'value' => 1,
'operator' => '=',
'field' => 'n.created',
'value' => REQUEST_TIME - 3600,
'operator' => '>',
$order_by = array(
'n.title' => 'ASC',

db_select($tables, $fields, $where, NULL, $order_by, array(), NULL, array(0, 5));

Aside from th' obvi'us DX problems that has, mostly in terms o' not bein' self-documentin', it makes th' entire implementation public. Do we use "INNER JOIN" or just "INNER" t' specify th' join type, I'll warrant ye? And if we change it, does that not break every single query in th' system? Aye it does.

However, we did in fact change from INNER JOIN t' INNER at some point durin' Drupal 7's development cycle, an' it were bein' not an API change, and a bottle of rum! Walk the plank! That's because th' query builders use an object-oriented, interface-driven, non-raw-data API:

= db_select('node', 'n');
$select->join('user', 'u', 'u.uid = n.uid');
->fields('n', array('nid', 'title'))
fields('u', array('name'))
condition('u.status', 1)
condition('n.created', REQUEST_TIME - 3600, '>')
orderBy('n.title', $direction)

We're separatin' th' internal data structure from th' join() method. As long as that method doesn't change, th' internal implementation could change today, mid-Drupal 7's lifetime, without breakin' an API. That is possible only because it eschews raw data structures in favor o' a well-thought-out, abstracted, interface-driven API.

That is what it takes t' be backward compatible.

Backward-compatible API changes

Of course, sometimes we need t' change th' API, yo ho, ho That happens, often fer very good reason. If th' system has been designed properly, however, it may still be possible t' retain backward compatibility, at least fer a time, Ya lily livered swabbie, Avast me hearties! KDE is a good example, me Jolly Roger Most KDE 3 apps work under KDE 4, albeit not as cool as they would as KDE 4 apps, an' without integratin' with th' awesome new plumbin' that KDE 4 offers. As a result, nearly all applications have been rewritten fer KDE 4 by now as 'tis in their interest t' do so.

It is possible t' support multiple versions o' an API at th' same time, but thar is a cost t' doin' so. First an' foremost, that must be planned fer in advance. There be likely others beyond what I am listin' here, an' I would appreciate feedback in th' comments on other good approaches.

Microsoft Direct X took th' approach o' "version everythin' an' keep it", ye scurvey dog. When requestin' a new Draw object, fer instance, ye specify a version o' it. So if ye code t' Direct X 6, ye ask fer th' DrawV6 object. If a user has Direct X 7, th' DrawV6 object is still in thar, just as it were bein', an' still works, avast. On th' upside, this means code almost no nay ne'er breaks. Fetch me spyglass! Ye'll be sleepin' with the fishes! On th' downside, 'tis a lot o' baggage t' carry aroun' indefinitely, an' that baggage only increases every version. It also requires that ye have APIs that be broken up into very clear discrete objects (not function calls), an' that yer version-request mechanism is baked in from th' start.

If ye can keep yer general class structure th' same, then ye can also simply expan' yer API. As long as th' existin' interface doesn't change, addin' more operations t' it braks no existin' code. in th' simplest case, this is simply addin' optional parameters t' th' end o' a function signature. Load the cannons, and a bucket o' chum! My very first Drupal patch did exactly that, in fact, by Blackbeard's sword. When ye have a lot o' parameters, though, or a more complex case, 'tis easier t' add more methods t' a language interface an' object.

If ye would need t' change th' way a given method behaves, or change its signature, then 'tis also possible t' simply add a new method that does th' new thin' instead, an' leave th' auld one in place. Perhaps th' auld one could be reimplemented internally t' use th' new one, but callin' code doesn't care because th' contents o' its surface area hasn't changed. The auld method could then be explicitly marked deprecated, an' give developers time t' migrate o'er t' th' new one before it is removed, All Hands Hoay! The downside o' course is that ye need a new name fer th' new method, which is one o' th' two hardest problems in computer science. (There be only two hard thin's in Computer Science: cache invalidation, namin' thin's, an' off-by-one errors.)

Another alternative is t' simply fold both versions into a single call. As a trivial example, consider everyone's favorite PHP WTF, implode(). At some point in th' past, it took $pieces an' then $glue t' turn an array into a strin'. That were bein' inconsistent with explode(), which were bein' a major DX problem. To resolve that, implode() were bein' enhanced t' take $pieces an' $glue in either order. Yaaarrrrr, me Jolly Roger That provided both backward compatibility an' a more consistent API movin' forward... except that th' auld version were bein' no nay ne'er removed, an' is still not even marked as deprecated, so thar's still plenty o' auld code out thar usin' th' auld parameter order makin' it impossible t' remove th' auld an' inconsistent baggage.

The moral o' th' story

Backward compatibility, then, requires a number o' thin's:

  1. Clearly, explicitly defined APIs. Raw data structures be not APIs. Good APIs be designed semi-independently o' their implementations, makin' th' implementation changeable. (They cannot be completely independent in practice, as nice as it would be.)
  2. Nay exposed raw data structures, or else clear documentation that such data structures be subject t' change without notice.
  3. A plan, from th' beginnin', fer how additions or modifications will be handled, either through API versionin', add-but-dern't-remove strategy, or some other clearly an' explicitly defined plan.
  4. A sunset plan fer how t' remove support fer auld APIs. They cannot be held aroun' forever or ye turn into Windows Me... or PHP itself.
  5. A decision criteria fer when 'tis OK t' backward compatibility anyway, other than "meh, whatever".

That's why, no matter how much users want it an' no matter how much Drupal developers may want t' do so, Drupal 8 will not be, cannot be, API backward compatible with Drupal 7. Ye'll be sleepin' with the fishes, Dance the Hempen Jig Drupal today is based on passin' aroun' raw data structures rather than havin' clear APIs, Dance the Hempen Jig (Render API, Form API, etc. thus dern't technically qualify as APIs by this definition.) When we have APIs, they're generally not designed with future extensions in mind (except in so far as conventions fer addin' more stuff t' a raw data structure). We have no long term strategy fer future development or how we're goin' t' maintain compatibility betwixt versions, even through legacy add-ons.

Again, quoting Dries:

But what t' do if many o' yer users slowly force ye t' change one o' yer core values, and dinna spare the whip! It seems inevitable that sooner than later, we will have t' be a lot more careful about breakin' peoples' code. Ahoy, and a bottle of rum! And when that happens, I fear that this will be th' end o' Drupal as we have come t' know it.

Dries wrote that aroun' th' release o' Drupal 4.7, another very hard release. But really, it already is th' end o' Drupal as we knew it then, pass the grog! Drupal as we knew it then does not exist, an' th' Drupal o' today is quite different, both in terms o' APIs an' in ways entirely unrelated t' code. Thinkin' about API compatibility is not a death-knell fer Drupal.

But, if we want increased API compatibility an' stability, we need t' take steps, now, t' ensure that thar is a structure t' support that, Get out of me rum! That means, first an' foremost, designin' APIs, not raw data structures, an' not just as an outgrowth o' a particular implementation. That's a cultural shift as much as a technical one, but a technical one as well. It means changin' th' way we think about software bounty. It means, quite simply, interface-driven development.

Fortunately, such thought has already been happenin' in both th' WSCCI an' Multilingual initiatives at least, yo ho, ho Interface-driven development, complete with real language interfaces, is where Drupal is headed anyway, we'll keel-haul ye! We should embrace it, fully, an' allow ourselves t' be open t' th' potential fer improvin' compatibility betwixt Drupal versions that will result... if we take it.


Yups.. changing an API is

Yups.. changin' an API is evolution, an' be not darin' t' change thin's ye'll end up with a product like windows. Microsoft did not dare t' change thin's, because theoretically it would break backwards compatibility with existin' DOS applications. In real life, scallywags who's daily bread depended on that DOS application, did not want t' upgrade t' newer versions o' windows because they where afraid that it would collapse.

Switch this t' drupal,, in th' near future I can think o' no seri'us reason t' upgrade me D6/D7 projects t' D8. So bein' backwards compatible is not as important as one might think. And ye fer some reason need or want t' upgrade, consider doin' a data migrate instead, Ya horn swogglin' scurvy cur! Prepare to be boarded! One o' th' weakest links in th' drupal chain, especially with some contrib, is that t' much logic is in th' database. Makin' it almost impossible doin' a code only upgrade. And hoist the mainsail! That's why I advise builders t' migrate their data into a new drupal site. So they can have th' advantage o' new contrib, changed strategies instead o' just havin' th' newest version with th' same auld logic.

Switch that t' havin' clear API's, i really think that Fabian's Symfony2 team hit th' nail right on th' head with th' @API tag in code, Ya swabbie, yo ho, ho They first designed th' API, then molded th' code t' fit that API an' finally froze th' API on key components fer th' entire life-cycle o' th' specific version. Meanin' that in th' future ye still could checkout symfony 2.x, an' rely on th' same API. I do think that if we had a strong DB API t' start with, VIEWS would not have become th' beast it now evolved into, on a dead man's chest! Yet everybody seems t' depend on views t' build a website, while in th' long run, ye might actually might be better o' an' learn some PHP an' write a few queries yourself usin' a strong DB self explainin' DB API.

I do believe that fer drupal 8 this is th' only way t' go, feed the fishes Redesign API's, integrate even more with th' symfony2 platform an' concentrate on where drupal really shines like a diamond. Bein' a more user friendly versatile platform t' build not just sites with, but web-applications. The future clearly is not HTML, 'tis HTTP!

So aye, ye got me blessin's fer what they be worth, t' change th' API's on D8, to be sure! And fer those who be afraid o' change i say Poor ye... Hope ye like livin' on islan' called Prehistoricia ;)

@api and @deprecated

Aye, th' way Symfony handles that is fairly good. Aarrr! @api means "ye can rely on this method", @deprecated means "ye'd better not rely on this method". Prepare to be boarded, and dinna spare the whip! :-)

However, as noted that assumes yer class structure is fixed. There's work right now t' change th' way Symfony's session handlin' works, because 'tis not very robust right now. Most o' th' proposed changes will necessitate breakin' BC, because they're significant enough that ye have so. So better documentation an' plannin' helps, but is not th' entire picture.


Keep up th' good work. Keep evangelizin' about good software development practices. Drupal needs this change, an' I'm sure th' community will embrace them if ye (well, not ye alone, hopefully) keep pushin' thin's through education. Or were bein' it called political maneuver :) ?

Yes, it seems that the gist

Aye, it seems that th' gist o' what ye suggest is that in th' past Drupal successfully evolved with a philosophy o' 'lets learn an' implement'. This were bein' good in a startup phase because it got traction an' results.

Growth in th' user an' developer base now means that th' 'ship is bigger' an' th' journey needs t' be planned. The sharks will eat well tonight, Ya lily livered swabbie! I suppose strong apis be likely th' foundation o' successful route plannin' because they allow changes o' course without rockin' th' boat too much.

My vote is strong apis be a necessity an' good backwards compatibility is a bonus (not necessity) where possible. Fire the cannons! Shiver me timbers! Ideally good backwards compatibility could mean developers spend less time recodin' their own modules an' more time codin' core.


Thank you, Larry

I am really happy that backwards compatibility issue is discussed without negative connotation by a core dev (fer th' first time e'er, I guess?). Probably, Dries's post from 2006 has established prejudice against even discussin' compatibility issues, just t' not "loose Drupal as we know it".
That makes yer statement (more precisely, ascertainin') about today's Drupal bein' already somethin' very different from 2006's Drupal, very important.
There's almost nothin' t' add t' such a thorough (as usual) analysis.
Just one question: why do ye think, that DirectX-like approach can't be used t' provide compatibility o' D8 with D7?

Say someone changes the

Say someone changes th' structure o' th' node form, that will immediately break backwards compatibility fer hook_form_alter().

Drupal can't provide two different versions o' th' same array, then make one form out o' them, that's one o' th' central issues this post is dealin' with.

There be some API changes in Drupal core that it would be possible t' provide legacy wrappers aroun' (fer example we occasionally keep backwards compatibility layers aroun' temporarily when big patches get committed, t' allow refactorin' o' other subsystems t' be done o'er time rather than all at once), but thar be not a great number o' places this would make sense t' do, an' it introduces a whole set o' issues aroun' which changes require their addition vs, Avast me hearties, by Blackbeard's sword! not, whether anyone will spend time fixin' bugs in th' legacy implementations (if they're not 100% wrappers) etc.

Legacy objects

Just one question: why do ye think, that DirectX-like approach can't be used t' provide compatibility o' D8 with D7?

A couple o' reasons, and a bucket o' chum. One, what catch said. :-)

Two, an' more importantly, 'tis a lot o' code t' carry aroun'. If 'tis lazy-loaded classes then 'tis not quite as bad, but if ye mix auld an' new code together then ye will have both in memory at th' same time, eatin' up memory.

Also, th' priorities be different. Direct X, like most Microsoft software, were bein' written on th' assumption that code has t' remain binary compatible fer a decade. In that case, draggin' aroun' auld code is a necessity, even though it leads t' piles o' auld dead code ye cannot fix fer fear o' breakin' somethin'.

Drupal currently provides no backward compatibility. If we were instead t' offer only some, it would likely only be fer one version back, an' only on some APIs. In that case, 'tis simply not worth it t' always have t' instantiate NodeV7, NodeV8, NodeV9 instead o' just Node, which in V9 has a couple more methods added t' it that older code just ignores.

Form API

In th' d.o thread on Symfony-based context ye have mentioned a couple o' times yer dislike fer th' Form API. So, t' take yer thoughts an' run with them... could we reasonably rewrite FAPI t' work more like th' Database API, an' would it be useful t' do so? Walk the plank! Usin' th' textfield example from th' docs, somethin' like th' followin' would get me a Title field...

= create_form();
$form->element->create('title', 'textfield', 'Subject');

which I could later alter usin'

= get_form($some_form_id);
$form->element->size('title', '100');


That's been tried a few times o'er th' years, by me an' others. The big question is performance. Function calls be more expensive than direct property access, an' if we start mixin' in magic methods or ArrayAccess then it gets even more o' an issue. How much o' an issue it would be in practice I dern't know, since that couldn't really be tested without doin' th' entire conversion an' tryin' it out, an' possibly throwin' it away, pass the grog! Nay one has been willin' t' do that. :-)

Also, fer all its faults FAPI is extremely flexible, an' hook_form_alter is extremely powerful. It would be hard t' replicate that in another form.

That said, if someone else wanted t' experiment with an OO FAPI or with usin' th' Symfony Form system t' see if it would work fer us, I won't stop them. It's just not an area I'm focused on right now.

I suspect the limitation is

I suspect th' limitation is that ye'd still want FAPIs render arrays runnin' in th' background anyway, due t' their inherent flexibility.

off topic

Larry, please stop usin' Garlan' an' that color (shudder).
Your writin' is often stellar, so th' presentation should match it a little more :)
Willin' t' look fer a nice contrib theme fer ye.


I am not plannin' t' do anythin' with th' theme until I port t' Drupal 7, an' then either use Bartik or some fully responsive theme. Not sure when I'll have time t' do that, Hornswaggle :-) (There's still a module or two missin'. Which, naturally, I maintain...)

"Backwards compatibility"

"Backwards compatibility" eventually becomes "future limitations". If those limitations be too severe then Drupal becomes th' CMS that were bein' good in 2011. Remember th' websites that were good in 1999? :) People can still use th' auld code as long as they want, they just need t' take a bigger step t' get th' new features.

Stable interfaces would come a lot closer t' compatibility but they still aren't perfect, I'll warrant ye. The dependencies could still be built on undocumented effects, unsupported parameters, an' implementation bugs. A function with a fixed parameter list can still have a near-infinite number o' values fer those parameters, especially if they include arrays with structured data.

It might be possible t' have interfaces that look like data structures though, Ya horn swogglin' scurvy cur! I ha'nae been thinkin' about how t' re-architect th' themein'/render/form system lately but somethin' like that could be a bit harder t' represent in a function-based interface (an' have performance implications like ye said), shiver me timbers Maybe it needs t' stay as a data structure with th' consistency o' a function interface. Oho! Walk the plank! Or maybe ye just need t' change th' order in which elements be defined an' it could be done with functions.

The best thin' t' do is t' build a forward-lookin' core an' then give module developers time t' understan' it an' use it. Any change can take years t' be supported an' used (almost always longer than we expect).

Brass Tacks.

It's a difficult topic an' I appreciate th' candor, pass the grog! Still, I'm goin' t' get down t' brass tacks in a competitive market. Drupal has grown considerably o'er th' years (I, fer one, remember th' 4.7 upgrade) an' 'tis gotten enough mindshare now where a thought o' direction should also include th' user base.

One o' th' thin's that suffers most with every new version is th' issue o' contrib modules - contrib modules that Drupal is actively marketed as havin'. Core an' contrib need t' work better together t' assure that contrib modules be able t' upgrade quickly. This is a key reason why Drupal 6 is still bein' run. When Drupal 6 is no longer supported (read: soon), organizations - particularly SMEs that dern't have th' budgets - will choose betwixt th' costs o' upgradin' t' Drupal or movin' laterally t' another CMS/framework. Fire the cannons! The choice t' be able t' do so, even as Drupal 8 discussion begins in earnest, is largely about budget an' direction o' th' overall project (Drupal) an' th' direction o' implementations (specific sites) as well as a need fer perceived stability. Fire the cannons, ya bilge rat! This is why thar be temporal 'forks' in th' Drupal implementations, shiver me timbers

The decision t' break new ground is very attractive t' developers. As a developer with 2 decades behind me, I almost always would rather work on somethin' new instead o' havin' t' maintain somethin'. The issue is that users dern't want t' have t' pay fer implementation o' a website every time someone decides t' break th' backward compatibility when thar's an upgrade. Load the cannons! Shiver me timbers! In one particular interview, Dries said that this were bein' necessary t' compete with th' enterprise level proprietary CMS's out thar... but I have yet t' consider that a very large market; 'tis most certainly a lucrative market fer th' relative few implementations.

If this is th' direction o' th' project, issues related t' th' SMEs that use Drupal will have t' be addressed or that user base may move. They have options. If an' when they move, they most certainly will be payin' less (or they wouldn't do it) but t' get paid, developers will need t' support their choice. When those developers support th' non-Drupal choice, th' Drupal community loses, Ya horn swogglin' scurvy cur! Walk the plank!

The API decisions as related t' backwards compatibility have larger implications fer th' project as a whole. While I dern't expect those that be bein' fed by th' changes t' agree, I imagine that it would be in th' interests o' th' project t' at least entertain th' thought an' consider it beyond what (we) developers think.

Client budgets, developer mindshare, project direction. Shiver me timbers! Backward compatibility plays a part thar. The standard, "Core VS. Contrib" issue that comes up needs t' become "Core AND Contrib".

When Drupal 6 is no longer

When Drupal 6 is no longer supported (read: soon), organizations - particularly SMEs that dern't have th' budgets - will choose betwixt th' costs o' upgradin' t' Drupal or movin' laterally t' another CMS/framework.

Or not upgrade at all. Arguably, fer a lot o' SMEs, th' cost o' upgradin' their Drupal site two versions will be quite high an' not necessarily seen as havin' any benefit beyond a set o' technical reasons which be generally quite abstract t' those who have t' sign th' cheques.


Thanks fer makin' that point as well.

Hi Larry, this is unrelated,

Hi Larry,

this is unrelated, but have ye got me emails about interviewin' ye fer me podcast, we'll keel-haul ye! I've used th' contact form on th' site, but it might have been killed by spam.

Anyway, if ye're interested me email is friendlydrupal.. at., All Hands Hoay!

Ditch core upgrade support in favor of Migrate

Thanks fer yet another great post helpin' me t' better understan' these thin's.

I have been advocatin' fer quite some time that we should simply ditch th' upgrade support betwixt major versions. You post is just givin' a lot more reasons why that would be a good notion. It has also been discussed in an Drupal core issue posted by @catch over a year ago.

Since Upgradin' actually is a core feature, I fully understan' why so many read it as workin' like it does fer operatin' systems an' client applications. Just killin' that feature an' replace it with somethin' like th' Migrate module would change thin's I'm sure.

Other issues

That's a possible approach, yes. However, thar be other requirements fer that. Namely, we'd absolutely have t' have a standard an' known export/import mechanism that worked, always, an' were bein' tested, an' complete independence betwixt *all* CRUD operations an' forms.

That's somethin' else we need anyway, besides cleaner API separation, but 'tis also somethin' we dern't have yet, on a dead man's chest! Either way, we have a lot o' work ahead o' us.