Won't this change the behavior for apps who have already run their migrations in production?

@driesvints if they have already run their migrations, how this change the behavior of those apps?

Currently, when adding a binary column it is always a BLOB equivalent column. but when changing to binary column it depends on the previous column's length and default to LONGBLOB if it has no length. for example:

Schema::create('tests', function (Blueprint $table) {
    $table->string('string_to_binary');
    $table->integer('integer_to_binary');
    $table->binary('binary_column'); // is always `BLOB`
});

Schema::table('tests', function (Blueprint $table) {
    $table->binary('string_to_binary')->change();  // changes to `TINYBLOB` because it already has the length of 255.
    $table->binary('integer_to_binary')->change(); // changes to `LONGBLOB` because it already has no length.
});

Please check this function on Doctrine DBAL;

I think it is inconsistent behavior but if you think this is the expected behavior or is a breaking change, I can revert changes to binary column modifying. Please let me know. Other changes are not breaking at all.

Their migrations which are part of their app will still be run in development. If they run them in development after this PR is merged, their development databases will be out if sync with production.

OK, I reverted changes on binary I'll send that to master later.