CCK node types have "fields." A field can store data in one or more database columns or even no columns in the case of a computed field. Views have "fields" indicating what data will be displayed in lists or tables. Fields can be values from columns or arbitrary data returned by a handler function. Schema API defines tables to have "fields," too, but a Schema API field is really a database table column. This is very confusing, and if we release D6 with this terminology in place we will be stuck with it forever.

The only reason Schema API uses the term "field" instead of "column" is that the functions db_add_column() and db_change_column() already existed (they are pgsql utility functions in update.php). Frando and I felt it would be easier to get the Schema API patch in if we did not try to rename them. Now, I realize that was a mistake.

I presented this argument at the Boston Drupal User's Group meetup last night to 9 Lullabots, Moshe, and other developers and got wide agreement, no dissents.

The attached patch renames fields to columns. It also renames the old db_{add,change}_column functions to db_old_{add,change}_column (while officially only for pgsql they also work for mysql in most cases and some code (e.g. Views) uses them that way so we shouldn't put "pgsql" in the name). It's long patch but is little more than a big search and replace. With this patch applied, Drupal installs new and upgrades from D5 cleanly and results in a no errors on the schema.module comparison report. (The one exception to that statement is in block.module, http://drupal.org/node/190128, which is an unrelated bug.)

I'd like to get comments on this change from merlinofchaos, karens, and yched since they are/will be major users of Schema API; do they agree that the current use of "field" is confusing?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Status: Needs review » Needs work

First, I want to say that I whole-heartedly support this API change, even though it is very late in the release cycle. Barry's point is very compelling, and we risk generations of confused developers if we don't fix this right now. Plus, it gets rid of a long-standing developer confusion point: that the seemingly db-agnostic "db_add_column" function is actually for pgsql only. This is only further confusing now that there are both db_add_column and db_add_field functions.

About the patch itself, though:

a) Big, enormous, flashing, blinking, flaming, somersaulting -1 to db_old_add/change_column. If we're going to make an API change, it should go all the way, not give us legacy stuff for a release.
b) The old calls to the PG-specific db_add_column should be updated to use the new schema API function. From looking at the function signatures, it looks like they are almost identical, so hopefully isn't too much hassle. And looking at the bodies of the two, there doesn't seem to be anything special that db_add_column was doing that db_add_field can't just do.

yched’s picture

Big +1 on the proposed changed. I've thought that many times, but never actually took the time to word it.
Unfortunately, I heve absolutely no time for now for anything more than casting my vote :-(

webchick’s picture

Title: Schema API: rename field to column » Beta-breaker: Schema API: rename field to column

Bumping this to critical, and beta-breaker.

webchick’s picture

Priority: Normal » Critical
Gábor Hojtsy’s picture

I think it is very late in the cycle to do such a huge change. I focus on bug fixes and stabilizing what is there, not modifying it in huge scales. You need to convince Dries if you feel strong about this.

chx’s picture

you definitely need to drop the old functions that's a no go but before doing that, about the change... if views and cck can use fields in two different sense then why can't core have a third? you already did a change i have not really agreed with --moving schema into install-- but, ah well. Begin with convincing me that this is not a l’art pour l’art change and then Dries will be piece of cake.

chx’s picture

Title: Beta-breaker: Schema API: rename field to column » Schema API: rename field to column
Version: 6.x-dev » 7.x-dev
Category: bug » feature
Priority: Critical » Normal

Nothing is broken. I would not even call this an API bug -- an API bug is something you can't do but you really should either because it's just too logical, too much sought after or simply it was possible in an earlier Drupal. Here, this is an API enhancement only.

killes@www.drop.org’s picture

I really fail to see how anybody could think this was a good idea for D6 at this time.

KarenS’s picture

I like the change a lot, and would definitely +1 it if it was earlier in the cycle, but I think I agree it is just too late to do this, especially since I agree with Angie that we also need to get rid of the legacy function at the same time. Even though this is an API, couldn't we still change it in D7? I'm not sure we're really stuck with it if we don't change it now, it just would have been much much cleaner to get it 'right' the first time. Plus I suspect that once we get Schema API in wide use we will see other API changes/enhancements we'll want to make in D7.

webchick’s picture

Even though this is an API, couldn't we still change it in D7?

We can, yes. Our thought was that if we fix it *now*, we annoy roughly 25 module maintainers at having to change one line of code in their install files per table, and at the same time save ourselves from hundreds of support requests over the next 24 months (or however long 6.x is supported) to the effect of, "I'm trying to use db_add_column, and it's not working. What gives?" Also the CCK confusion.

Sorry about the critical+beta breaker; my intent was, "If we don't fix this now, we won't be able to."

bjaspan’s picture

Category: feature » bug
Priority: Normal » Critical

"Fields in core" really requires that we fix Schema API not to mis-use the term "fields" when it means "columns." Otherwise, "field" will mean two subtly different and very confusing things.

Susurrus’s picture

This patch needs a reroll and to fix what webchick said in #1.

I wouldn't really qualify this as a bug report, but it needs some attention.

Anonymous’s picture

I agree that database rows have columns but I'm really only subscribing to watch since I also naturally use the term field and column interchangeably. I grew up calling a set of bytes a field and a set of fields a record then along came this thing called databases that needed new terms from some reason. Now we call a set of bytes a column and a set of columns a row.

"Fields in core" - An administrator controlled column added in a content type for specific data to be inserted into a node.

Is that a fair description of "Fields in core"? Doesn't "Fields in core" create a database column to store that data? Maybe "Fields in core" should be called "Content Type Columns" to remove the confusion expressed here.

catch’s picture

If you look at CCK fields, you note that many of them contain more than one column, or create their own tables, and that fields refers to a field in a form, not in a database. Hence, not a column.

Anonymous’s picture

@catch: Given that, "Content Type Data" would then make sense because a form field value must be stored in a table column and the term data would cover both field and column.

column - data stored in a database.
field - data presented in a form.
data - a collection of information stored in database columns and presented in form fields.

catch’s picture

@earnie: content type data sounds like the settings for content types, only a part of which has anything to do with fields. Also, the plan is to have fields attachable to entities other than nodes - for example users, taxonomy terms, comments - and 'content type data' doesn't cut it for that purpose.

Anonymous’s picture

I agree with the idea of the patch and I agree that the db_old_add_column and db_old_change_column functions need attention.

Susurrus’s picture

Well here's something to get the ball rolling. It's been updated for HEAD and doesn't include db_old_* functions. Seems to cause a bunch of tests to fail however so leaving as CNW.

Crell’s picture

Let's postpone this until after #225450: Database Layer: The Next Generation lands, please? I really don't want to have to redo the schema portion of that patch again. :-( (Postgres testers, please help!)

webchick’s picture

Status: Needs work » Postponed

Sounds reasonable. I'm not actually even sure this makes sense to do now, which is why we tried to get it in /before/ Drupal 6 was released. ;)

eaton’s picture

Sounds reasonable. I'm not actually even sure this makes sense to do now, which is why we tried to get it in /before/ Drupal 6 was released. ;)

The biggest plus to renaming it 'column' would be potential compatability with the Views table definition style. It would be great if we could use a single schema to gather up all the information needed by both modules...

Crell’s picture

There are other things that need to happen to Schema API to make it more Views friendly, too. I have a few notes from talking to merlin in Boston, but those are blocked on DB TNG getting committed (but then, what isn't these days?).

moshe weitzman’s picture

Status: Postponed » Needs work

Why would we postpone this? It was a good idea for 6, and is still a good idea for 7 IMO.

bjaspan’s picture

Bumping. DBTNG and Field API have both landed. The time for this patch has come.

bjaspan’s picture

Status: Needs work » Needs review
FileSize
485.99 KB

This is a large patch but it does nothing but replace "field" with "column" in a variety of contexts. This command gives a pretty good idea of what changes (it lists all the lines in the patch that represent changes to function names/signatures):

 grep '^[+-].*function ' patches/schema-field-to-column-190162-25.patch

One of the places I renamed field to column is the new database API. I think that is correct but am not 100% sure. If it is not, however, then we are back to lots of naming conflicts.

Damien Tournoud’s picture

Changing (Insert|Update)Query::fields() to (Insert|Update)Query::columns() seems ok.

But having both DatabaseStatement::fetchField() and fetchColumn() seems messy. DS::fetchColumn() is defined in PDO, I'm not sure from the top of my head why we need the custom fetchField().

Status: Needs review » Needs work

The last submitted patch failed testing.

catch’s picture

fetchField() as the drop in for db_result() is extremely handy. Since in this case it means 'get me the value of one row from one column' fetchField() doesn't seem so bad. I don't think it'd be a terrible thing to rename everything else, and then try to work that one tricky case out in a followup.

bjaspan’s picture

Status: Needs work » Needs review
FileSize
495.79 KB

re #26: I do not understand. After this patch, DS:fetchField() is renamed to DS::fetchColumn(). There is no more fetchField(), so there is no "both" to be messy. But maybe it's just late and I'm confused.

Some more queries got changed to use DB:TNG today so the patch is already out of date. Maybe that's why you think both functions still exist?

Rerolled.

Status: Needs review » Needs work

The last submitted patch failed testing.

bjaspan’s picture

Status: Needs work » Needs review
FileSize
502.01 KB

Rerolled again. I verified that all Database tests pass, I'll leave the rest to the bot.

Crell’s picture

fetchColumn(): http://us3.php.net/manual/en/pdostatement.fetchcolumn.php

For DBTNG, we wanted to have a "fetch the Xth column of every result set into one big array" operation. We were also trying to minimize the differences between the DatabaseConnection and DatabaseStatement classes and their parent classes, for compatibility, E_STRICT, and easier learnability for new-to-Drupal PHP folk. So we couldn't just yoink that method name for that operation, nice as that would have been. Instead, we added fetchCol() for "get me a one element array", and added the fetchField() wrapper for "get me one specific field from the next result set" (which maps directly to db_result() and is rarely called more than once now that we have all the fetch utility methods). fetchColumn() is therefore effectively deprecated as far as DBTNG usage is concerned to try and minimize confusion in the recommended APIs. I believe it's not even mentioned in the handbook docs.

If we are going to rename all of the field*() methods to column*(), we need to take that into account. There are other places we use "column" to mean something other than "name of field in the table itself". Yes, "field" also means "CCK field"... There simply aren't enough nouns to go around.

To be honest, I'd prefer to not rename it. We've spent the last 8 months trying to train people on the new API with field*(). I am not convinced that the change is worth it given the work we've already put into training people on the new API, especially as it does not eliminate confusion, it simply moves it elsewhere without solving it.

bjaspan’s picture

Are you suggesting we not rename fetchField(), or not rename "field" at all in the DB API? If the latter, are you also suggesting we not rename it in the Schema API either, e.g. just mark this issue "won't fix"?

Crell’s picture

Renaming fields() but not fetchField() would be the worst option, IMO, as it creates inconsistency in the main part of the API. I could arguably see renaming it for schema only, as you're thinking about the table much more structurally there than about the data in it, but that could also be a mental inconsistency.

So yeah, either schema API only or won't-fix period, as renaming fields to columns doesn't completely solve the problem either.

bjaspan’s picture

On Nov 7, 2007 I wrote:

If we release D6 with this terminology in place we will be stuck with it forever.

Perhaps I was right. ;-)

moshe weitzman’s picture

@Crell - I don't think we get the luxury of a "complete solution" here. What Barry and others are trying to clarify is the horrid confusion between a field in the CCK sense and a field in the schema/DB sense. Do you have a proposal for that? In #19, you specifically asked to postpone this until after DNTNG lands. Now we are here, in the same release, and you are saying "too late". I'm paraphrasing wildly but still ...

bjaspan’s picture

@moshe: Hey, good point re #19! :-)

catch’s picture

@Crell, I reckon there's about 50-100 people tops who've used dbtng more than once or twice, so if we change now and a few core contributors have to relearn a couple of methods, that seems like a better option to me than being stuck with this forever, and then trying to explain it to x000 contrib developers.

The ->fetchCol() and ->fetchColumn() when there's a fetchColumn() in PDO as well is a bit unfortunate, but I don't think it should hold this up.

Crell’s picture

How big of an issue is SQL field vs. CCK field, really? TBH I've never had a problem confusing the two, because they're in two separate parts of my brain. One is an abstract data unit thing, and the other is a physical part of an SQL table. I can't recall ever having a problem confusing the two (even though more often than not a CCK field corresponds directly to an SQL field.) Admittedly I am not the average developer, but I used to be at one point and even then didn't have a problem.

What makes field vs. column confusion less of a problem than sql field vs. CCK field confusion?

catch’s picture

It's things like this which will get confusing:

http://api.drupal.org/api/function/field_read_field/7

(imagine if ->fetchField() actually showed up on api.drupal.org to illustrate the similarity, for now the summary of db_result will do).

bjaspan’s picture

Here's another: http://api.drupal.org/api/function/hook_field_columns/7 returns a schema structure with column definitions, which will then be stored as the 'fields' element of a table definition. got that?

It's about to get worse, too. #415044: Indexes for field storage. is renaming hook_field_columns, which currently only returns column specs, to hook_field_schema, which can return columns and indexes. Unless we change Schema API's "fields" to "columns", we get to choose between:

function text_field_schema() {
  return array('columns' => ...);
}

which returns a "schema structure" with a 'columns' element even though schema structures have 'fields' elements and not 'columns' elements, or

function text_field_schema() {
  return array('fields' => ...);
}

in which a Field API function is returning an array containing a 'fields' element which is not an array of Field API field structures.

I can't decide which one is more horrible.

Dries’s picture

As it stands, I think we should go ahead with this change. However ...

I've read #32 twice now and I don't see why changing the database abstraction layer is a problem -- maybe I couldn't parse what Crell was saying -- the explanation seemed to contain some unnecessary details. Either way, I think renaming field to column in DBTNG will actually make the database abstraction layer easier to grok. I remember being confused about "fields" in the database abstraction layer -- it didn't map onto my mental model of columns.

Crell, can you explain, once more, in simple terms, maybe with an example, why you are opposed to this change?

I will make the final decision after Crell's explanation.

Status: Needs review » Needs work

The last submitted patch failed testing.

Crell’s picture

One of the goals for the DBTNG layer was to keep the API as close to PDO as possible, for a lower barrier to entry for new developers. (PDO is part of PHP, so there should be more people using PDO than using Drupal, if not yet then there will be as more people give up on PHP 4-era coding styles.) That means not changing behavior unless we really have to. We did in a few places, but only with good security reasons involved.

There is a PDOStatement->fetchColumn() method in PDO. What it does is fetch a single field from the next row; essentially the same as db_result() in Drupal 6. We cannot remove that. We could override it, potentially, but if we change its semantics then we are breaking the PDO API, and possibly E_STRICT as well if the method signature is not precisely the same. (Yes, I am striving for E_STRICT compatibility.)

There is also a new primitive we added to DatabaseStatement, fetchCol(). fetchCol() fetches the Nth field of every record in the result set as an array; It's most common use is for, say, db_query("SELECT nid FROM {node} WHERE type='page')->fetchCol(); to get an array of the nid of all page nodes in a single shot (or some more useful query).

To avoid confusion with that, and because for many people (myself included) "column" implies the full result set not just a single record (honestly I never understood calling it "fetchColumn()"), we settled on "field" for "element within a record". Field is regularly used interchangeably with column elsewhere IME.

Point being, "column" already has semantic meaning. It has meaning that is bound to PDO, and our ability to change it is quite limited.

Now, CCK/Field API also uses the word "fields". Actually, so does Views, and Views "fields" do not map 1:1 to CCK fields either. (A CCK field usually maps to a Views field, but not all Views fields correspond to a CCK field; nor do they always correspond to a database field, although they do more often than not when we're not talking about CCK fields.) So that's at least three different meanings of "fields" that we already have.

No, I am not saying that is not a problem. I am saying that renaming one of them (DB API/Schema API) to "column" doesn't solve anything, because it just introduces another confusion between column (single element) and column (single element across all records in a result set).

webchick’s picture

So what if we rename ->fetchCol() to ->fetchColumnResults() or something?

The fact that there's both ->fetchCol() and ->fetchColumn() anyway (since we can't do anything about that last one) strikes me as a DrupalWTF that we ought to fix.

Crell’s picture

fetchCol() ==> fetchColumResults() I could deal with, although it's a somewhat long name and none of our other fetch() methods have "results" in them. It wouldn't change the fact that we're already using "column", though, which is the problem for renaming fields to columns.

catch’s picture

But whether it's the first result from a column, or all results from the column in an array, it's still about a database column. Better than fetching an array of results from a database 'field' - which is what db_add_field() basically implies we call them now.

bjaspan’s picture

So PDOStatement->fetchColumn() == "D6 db_result()" and is a fixed point. I might agree with you that it is a questionable name, but in any case we can't change it or remove it.

We created DatabaseStatement->fetchField() which == PDOStatement->fetchColumn(). In fact,

  public function fetchField($index = 0) {
    // Call PDOStatement::fetchColumn to fetch the field.
    return $this->fetchColumn($index);
  }

We created DatabaseStatement->fetchCol() which returns one column from all rows in a result set. Independent of the Schema API field/column naming issue, I suggest that fetchCol() is poorly named. Having fetchCol() and fetchColumn() is confusing, and "we don't abbreviate in Drupal core." Since it returns an entire column, perhaps fetchWholeColumn() or fetchEntireColumn()?

In any case, I still do not think I understand crell's objection... hmmm, maybe I just got it. Is it that you *agree* that having fetchCol() and fetchColumn() is confusing, but you feel that since we have fetchField() we can simply "ignore" fetchColumn() and thus avoid the confusion? If so, then by renaming field to column and therefore renaming fetchField() to fetchColumn(), we re-introduce the confusion that was avoided by "hiding" (not advertising) PDO's fetchColumn().

*If* that is your logic (and I realize it might not be), then I disagree with it. We already and always have PDO's fetchColumn() as part of our interface. We can't get rid of it. Wrapping it in fetchField() still leaves fetchColumn() in place. Instead, I'd suggest:

1. Renaming fetchCol() to fetchWholeColumn() or something.
2. Converting Schema "field" to "column", because Schema "fields" *really are* columns.
3. Removing the fetchField() wrapper entirely since once it is renamed to fetchColum() it is a useless wrapper.

bjaspan’s picture

Heh. I started my post at 11:30am and finished it at 2:10pm and apparently everything I wrote got written by someone else in the meantime. :-)

Crell’s picture

Yes, sorry, I should have been more clear. fetchColumn() is not documented as part of the Drupal DB API because we don't want people using it, since fetchField() is consistent with the rest of the API. (fetchField() was Dries' suggestion for a name, IIRC.) So currently in DBTNG, the only place column appears is in fetchCol(), meaning "a single field, all rows of a result set".

I dislike fetchCol(), too, and I am open to renaming it to something better if we come up with a good better.

bjaspan, if I understand you in #48 correctly, you're suggesting we rename field to column in the Schema API parts of the DB layer (which need to be cleaned up anyway), and drop fetchField() in favor of fetchColumn(), but leave fields(), addField(), etc in the query builders alone?

bjaspan’s picture

Well, crap. Firefox crashed and I lost a partially written response that I wrote over about 30-40 minutes while also talking in IRC (about Field API). Maybe I'll get motivated to write it again later.

Short re-write:

@crell: No, in #48 I was just limiting my comments addressing fetch*(). I still think we should rename field to column everywhere in schema and dbtng, but my brilliant summary, analysis, and argument went bye-bye, and anyway my finger keeps hovering near the "won't fix" button...

Anonymous’s picture

I've been following this debate for some time. I began my data processing career when databases were stored on punch cards and columns were the bits in the card that were interpreted to be characters. A field was a grouping of these columns that created meaningful data. One or more punched cards became a record of data. We carried this terminology to files where what we call in DBMS a row is a record and what we call in DBMS a column is a field. It wasn't until the popularity of DBMS that we changed the words.

All this to say, column and field are synonymous and that I find this fuss frivolous. I have yet to find in an online dictionary any definition given where column is used in the field of computing. I did find one for the word field at http://encarta.msn.com/dictionary_/field.html at #15.

KarenS’s picture

IMO, this is a massive change for little gain. Unless we remove every single reference to the word 'Field' we will still have both columns and fields and it will potentially be confusing to figure out when one is used over the other.

We have gotten used to the current terminology and it's not 'wrong' really. And this patch could break lots of things that are now working.

I think I would -1 this idea at this point. Note that I was in favor of making the change when this was first added, but I think we're just too far down the trail to do this now.

eaton’s picture

I'm still +1 on it, actually, because we're encountering a serious collision in terminology that will ultimately need to be resolved SOMEHOW.

'Fields' currently means:

  1. A database column
  2. A CCK entity, which can consist of one, several, or NO database columns
  3. A Views pseudo-column which exists as one, several, or NO database columns in the actual DB.

#2 and #3 are reasonably consistent (though they are defined and managed differently). If we're going to rename anything, #1 seems like the logical one -- it already has a more precise term -- column -- that would be appropriate.

webchick’s picture

I was a fan of this in #1, still a fan of it in #55. ;)

eaton’s picture

On the other hand, Crell's point is a compelling one. PDO has what is (IMO at least) a relatively crappy meaning for 'fetchColumn' and overriding it entirely leads to craziness.

Am I allowed to say that I just think PDO is dumb for using that? It's not helpful, but there it is.

bjaspan’s picture

re #56: I still don't understand the issue with fetchColumn(). Renaming 'field' to 'column' in Schema API does not mean we have to change fetchColumn(). Right now we are adding a new function named fetchField() that just calls fetchColumn(). If we do the rename, we'll just remove fetchField() and leave fetchColumn() untouched as it is now. What am I missing?

Oh, and removing fetchField() will make it more important to rename the DX-killing fetchCol(), which is a good thing.

catch’s picture

Yeah fetchColumn() is the least of our worries here I think.

Anonymous’s picture

'Fields' currently means:

1. A database column
2. A CCK entity, which can consist of one, several, or NO database columns
3. A Views pseudo-column which exists as one, several, or NO database columns in the actual DB.

Why not define 'Field' to mean a collection of data that represents something of value. Then it fits the three points you have without collision of meaning since each of the three then becomes a type of field.

catch’s picture

@earnie "a collection of data that represents something of value" could describe a node, webpage, website, book. If you remove all specificity from definitions then yes anything can fit into them, but that doesn't solve the potential for confusion here.

catch’s picture

Version: 7.x-dev » 8.x-dev
Category: bug » task
Priority: Critical » Normal

Shame.

Pasqualle’s picture

subscribe

alansaviolobo’s picture

Issue tags: +Schema API

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.