From which Laravel version the change() method started requiring all column modifiers to be explicitly specified?

[tatata-keshi]

Hi!

The Modifying Columns section in the Laravel 11.x Upgrade Guide states that, in Laravel 10, column attributes were retained when calling change() even if each modifier was not explicitly specified:

Schema::table('users', function (Blueprint $table) {
    $table->integer('votes')->nullable()->change();
});

In Laravel 10, this migration would retain the unsigned, default, and comment attributes on the column. However, in Laravel 11, the migration must now also include all of the attributes that were previously defined on the column. Otherwise, they will be dropped:

However, the Laravel 10.x documentation seems to state the opposite:

When modifying a column, you must explicitly include all of the modifiers you want to keep on the column definition – any missing attribute will be dropped.

Because of this, the two documents appear to be contradictory.

I have also looked into the implementation of compileChange() in the schema grammars, and it seems that the behavior around column modification has changed across major versions.

Could you clarify from which Laravel version the change() method started requiring all column modifiers to be explicitly specified?
In other words, was this a behavioral change introduced in Laravel 10, or in Laravel 11?

Thank you.

[shaedrich]

That comes probably from the fact that Laravel stepped away from their doctrine dependency.

[hafezdivandari]

Since Laravel 10, we have native column modifiying, but for backward compatibilty doctrine dbal is also still supported, so if you have doctrine/dbal installed, column modifying will work as before but if not, framework will use native one which needs all attributes to be specified, here is the PR: #45487

Since Laravel 11, the doctrine dbal is removed from the framework and replaced with the native functionality, here is the PR: #48864