バージョニング規約Versioning Scheme
Laravelとファーストパーティパッケージは、セマンティックバージョニングにしたがっています。メジャーなフレームのリリースは、2月と8月の半年ごとにリリースされます。マイナーとパッチリリースはより細かく毎週リリースされます。マイナーとパッチリリースは、決してブレーキングチェンジを含みません。Laravel and its other first-party packages follow Semantic Versioning[https://semver.org]. Major framework releases are released every six months (February and August), while minor and patch releases may be released as often as every week. Minor and patch releases should never contain breaking changes.
皆さんのアプリケーションやパッケージからLaravelフレームワークかコンポーネントを参照する場合は、Laravelのメジャーリリースはブレーキングチェンジを含まないわけですから、^6.0
のようにバージョンを常に指定してください。しかし、メジャーリリースへ1日以内でアップデートできるように、私たちは常に努力しています。When referencing the Laravel framework or its components from your application or package, you should always use a version constraint such as ^6.0
, since major releases of Laravel do include breaking changes. However, we strive to always ensure you may update to a new major release in one day or less.
サポートポリシーSupport Policy
Laravel6のようなLTSリリースでは、バグフィックスは2年間、セキュリティフィックスは3年間提供します。これらのリリースは長期間に渡るサポートとメンテナンスを提供します。 一般的なリリースでは、バグフィックスは6ヶ月、セキュリティフィックスは1年です。Lumenのようなその他の追加ライブラリでは、最新リリースのみでバグフィックスを受け付けています。また、Laravelがサポートするデータベースのサポートについても確認してください。For LTS releases, such as Laravel 6, bug fixes are provided for 2 years and security fixes are provided for 3 years. These releases provide the longest window of support and maintenance. For general releases, bug fixes are provided for 6 months and security fixes are provided for 1 year. For all additional libraries, including Lumen, only the latest release receives bug fixes. In addition, please review the database versions supported by Laravel[/docs/{{version}}/database#introduction].
バージョンVersion | リリースRelease | バグフィックス期限Bug Fixes Until | セキュリティフィックス期限Security Fixes Until |
---|---|---|---|
5.5 (LTS)5.5 (LTS) | 2017年8月30日August 30th, 2017 | 2019年8月30日August 30th, 2019 | 2020年8月30日August 30th, 2020 |
5.65.6 | 2018年2月7日February 7th, 2018 | 2018年8月7日August 7th, 2018 | 2019年2月7日February 7th, 2019 |
5.75.7 | 2018年9月4日September 4th, 2018 | 2019年3月4日March 4th, 2019 | 2019年9月4日September 4th, 2019 |
5.85.8 | 2019年2月26日February 26th, 2019 | 2019年8月26日August 26th, 2019 | 2020年2月26日February 26th, 2020 |
6 (LTS)6 (LTS) | 2019年9月3日September 3rd, 2019 | 2021年9月3日September 3rd, 2021 | 2022年9月3日September 3rd, 2022 |
Laravel 6Laravel 6
Laravel6LTSは、Laravel5.8で行われた向上に加え、以降の変更で構成されています。セマンティックバージョニングの導入、Laravel Vaporとのコンパチビリティ、認可レスポンスの向上、ジョブミドルウェア、レージーコレクション、サブクエリの向上、フロントエンドスカフォールドをlaravel/ui
Composerパッケージへ移行、ならびに多くのバグフィックスとユーザービリティの向上です。Laravel 6 (LTS) continues the improvements made in Laravel 5.8 by introducing semantic versioning, compatibility with Laravel Vapor[https://vapor.laravel.com], improved authorization responses, job middleware, lazy collections, subquery improvements, the extraction of frontend scaffolding to the laravel/ui
Composer package, and a variety of other bug fixes and usability improvements.
セマンティックバージョニングSemantic Versioning
Laravelフレームワーク(laravel/framework
)パッケージが、セマンティックバージョニング規約に準拠しました。すでにこのバージョニング規約にしたがっている他のLaravelファーストパーティパッケージと統一されました。Laravelのリリースサイクルには変化はありません。The Laravel framework (laravel/framework
) package now follows the semantic versioning[https://semver.org/] standard. This makes the framework consistent with the other first-party Laravel packages which already followed this versioning standard. The Laravel release cycle will remain unchanged.
Laravel VaporコンパチビリティLaravel Vapor Compatibility
Laravel VaporはTaylor Otwellが構築しています。Laravel Vapor was built by Taylor Otwell[https://github.com/taylorotwell].
Laravel6は、Laravelのためのオートスケールされるサーバレス環境のプラットフォームであるLaravel Vaporとのコンパチビリティを提供しました。AWS Lambda上のLaravelアプリケーション管理の複雑さを抽象化し、同時にアプリケーションをSQSキュー、データベース、Redisクラスタ、ネットワーク、CloudFront CDN、その他と接続します。Laravel 6 provides compatibility with Laravel Vapor[https://vapor.laravel.com], an auto-scaling serverless deployment platform for Laravel. Vapor abstracts the complexity of managing Laravel applications on AWS Lambda, as well as interfacing those applications with SQS queues, databases, Redis clusters, networks, CloudFront CDN, and more.
Ignitionによる例外表示の向上Improved Exceptions Via Ignition
Laravel6は、Freek Van der HertenとMarcel Pociotによる、例外詳細ページのオープンソースであるIgnitionを採用しています。Ignitionは、Bladeエラーファイルと行番号の処理、一般的な問題に対する実行可能な解決策、コード編集、例外の共有、UXの向上などたくさんの利便性を以前のリリースから提供しています。Laravel 6 ships with Ignition[https://github.com/facade/ignition], a new open source exception detail page created by Freek Van der Herten and Marcel Pociot. Ignition offers many benefits over previous releases, such as improved Blade error file and line number handling, runnable solutions for common problems, code editing, exception sharing, and an improved UX.
認可レスポンスの向上Improved Authorization Responses
認可レスポンスの向上は、Gary Greenにより行われました。Improved authorization responses were implemented by Gary Green[https://github.com/garygreen].
以前のリリースのLaravelは、エンドユーザーに対しカスタム認可メッセージを取得し、表示するのが困難でした。これにより、エンドユーザーになぜ特定のリクエストが拒否されるのかをしっかりと説明するのも困難でした。Laravel6では認可レスポンスメッセージと新しいGate::inspect
メソッドを使うことでより簡単にできるようになりました。例として、以下のポリシーメソッドをご覧ください。In previous releases of Laravel, it was difficult to retrieve and expose custom authorization messages to end users. This made it difficult to explain to end-users exactly why a particular request was denied. In Laravel 6, this is now much easier using authorization response messages and the new Gate::inspect
method. For example, given the following policy method:
/**
* このユーザーが指定したフライトを見ることができるか判定
*
* @param \App\User $user
* @param \App\Flight $flight
* @return mixed
*/
public function view(User $user, Flight $flight)
{
return $this->deny('Explanation of denial.');
}
認可ポリシーのレスポンスとメッセージはGate::inspect
メソッドで簡単に取得できます。The authorization policy's response and message may be easily retrieved using the Gate::inspect
method:
$response = Gate::inspect('view', $flight);
if ($response->allowed()) {
// ユーザーはこのフライトを見る許可がある
}
if ($response->denied()) {
echo $response->message();
}
さらに、ルートやコントローラで$this->authorize
かGate::authorize
のようなヘルパメソッドを使用すると、このカスタムメッセージは自動的にフロントエンドに返されます。In addition, these custom messages will automatically be returned to your frontend when using helper methods such as $this->authorize
or Gate::authorize
from your routes or controllers.
ジョブミドルウェアJob Middleware
ジョブミドルウェアは、Taylor Otwellにより実装されました。Job middleware were implemented by Taylor Otwell[https://github.com/taylorotwell].
ジョブミドルウェアはキュー済みジョブの実行周りのカスタムロジックをラップできるようにし、ジョブ自身の定形コードを減らします。たとえば、以前のLaravelリリースでは、ジョブのhandle
メソッドのロジックで、レート制限コールバックをラップしていました。Job middleware allow you to wrap custom logic around the execution of queued jobs, reducing boilerplate in the jobs themselves. For example, in previous releases of Laravel, you may have wrapped the logic of a job's handle
method within a rate-limited callback:
/**
* ジョブの実行
*
* @return void
*/
public function handle()
{
Redis::throttle('key')->block(0)->allow(1)->every(5)->then(function () {
info('Lock obtained...');
// ジョブの処理…
}, function () {
// ロックが取得できない…
return $this->release(5);
});
}
Laravel6ではこのロジックをジョブミドルウェアへ移すことができ、レート制限の責任をhandle
メソッドはまったく負わなくて済みます。In Laravel 6, this logic may be extracted into a job middleware, allowing you to keep your job's handle
method free of any rate limiting responsibilities:
<?php
namespace App\Jobs\Middleware;
use Illuminate\Support\Facades\Redis;
class RateLimited
{
/**
* キュージョブの実行
*
* @param mixed $job
* @param callable $next
* @return mixed
*/
public function handle($job, $next)
{
Redis::throttle('key')
->block(0)->allow(1)->every(5)
->then(function () use ($job, $next) {
// ロック取得…
$next($job);
}, function () use ($job) {
// ロックが取得できない…
$job->release(5);
});
}
}
ミドルウェアを作成したら、ジョブのmiddleware
メソッドから返すことで指定できます。After creating middleware, they may be attached to a job by returning them from the job's middleware
method:
use App\Jobs\Middleware\RateLimited;
/**
* このジョブが通過する必要のあるミドルウェアの取得
*
* @return array
*/
public function middleware()
{
return [new RateLimited];
}
レージーコレクションLazy Collections
レージーコレクションは、Joseph Silberにより改善されました。Lazy collections were implemented by Joseph Silber[https://github.com/JosephSilber].
すでに多くの開発者がLaravelの強力なコレクションメソッドを楽しんで利用しています。すでに強力なCollection
クラスを補足するために、LazyCollection
クラスはPHPのPHPジェネレータを活用しています。巨大なデータセットをメモリ使用を抑えて利用する目的のためです。Many developers already enjoy Laravel's powerful Collection methods[https://laravel.com/docs/collections]. To supplement the already powerful Collection
class, Laravel 6 introduces a LazyCollection
, which leverages PHP's generators[https://www.php.net/manual/en/language.generators.overview.php] to allow you to work with very large datasets while keeping memory usage low.
たとえば、アプリケーションで数ギガバイトのログを処理する必要があり、ログを解析するためにLaravelのコレクションメソッドを活用するとしましょう。ファイル全体をメモリへまとめて読み込む代わりに、レイジーコレクションなら毎回ファイルの小さな部分だけをメモリに保持するだけで済みます。For example, imagine your application needs to process a multi-gigabyte log file while taking advantage of Laravel's collection methods to parse the logs. Instead of reading the entire file into memory at once, lazy collections may be used to keep only a small part of the file in memory at a given time:
use App\LogEntry;
use Illuminate\Support\LazyCollection;
LazyCollection::make(function () {
$handle = fopen('log.txt', 'r');
while (($line = fgets($handle)) !== false) {
yield $line;
}
})
->chunk(4)
->map(function ($lines) {
return LogEntry::fromLines($lines);
})
->each(function (LogEntry $logEntry) {
// ログエントリーの処理…
});
もしくは、10,000個のEloquentモデルを繰り返し処理する必要があると想像してください。今までのLaravelコレクションでは、一度に10,000個のEloquentモデルすべてをメモリーにロードする必要がありました。Or, imagine you need to iterate through 10,000 Eloquent models. When using traditional Laravel collections, all 10,000 Eloquent models must be loaded into memory at the same time:
$users = App\User::all()->filter(function ($user) {
return $user->id > 500;
});
しかし、Laravel6からクエリビルダのcursor
メソッドは、LazyCollection
インスタンスを返します。これによりデータベースに対し1つのクエリを実行するだけでなく、一度に1つのEloquentモデルをメモリにロードするだけで済みます。この例では、各ユーザーを個別に繰り返し処理するまでfilter
コールバックは実行されず、大幅にメモリ使用量を減らせます。However, beginning in Laravel 6, the query builder's cursor
method has been updated to return a LazyCollection
instance. This allows you to still only run a single query against the database but also only keep one Eloquent model loaded in memory at a time. In this example, the filter
callback is not executed until we actually iterate over each user individually, allowing for a drastic reduction in memory usage:
$users = App\User::cursor()->filter(function ($user) {
return $user->id > 500;
});
foreach ($users as $user) {
echo $user->id;
}
Eloquentサブクエリの向上Eloquent Subquery Enhancements
Eloquentサブクエリの向上は、Jonathan Reininkにより行われました。Eloquent subquery enhancements were implemented by Jonathan Reinink[https://github.com/reinink].
Laravel6はデータベースサブクエリのサポートにも、多くの新しい改善と向上を導入しました。例として、フライト(flights
)と目的地(destinations
)テーブルを想像してください。flights
テーブルは、フライトの目的地への到着時間を意味するarrived_at
カラムを持っています。Laravel 6 introduces several new enhancements and improvements to database subquery support. For example, let's imagine that we have a table of flight destinations
and a table of flights
to destinations. The flights
table contains an arrived_at
column which indicates when the flight arrived at the destination.
Laravel6の新しいサブクエリSELECTの機能を使えば、全destinations
と、一番早く目的地へ到着するのフライト名を1回のクエリで取得できます。Using the new subquery select functionality in Laravel 6, we can select all of the destinations
and the name of the flight that most recently arrived at that destination using a single query:
return Destination::addSelect(['last_flight' => Flight::select('name')
->whereColumn('destination_id', 'destinations.id')
->orderBy('arrived_at', 'desc')
->limit(1)
])->get();
さらに、クエリビルダのorderBy
関数も新しいサブクエリ機能ををサポートしています。この機能を使い、ラストフライトが目的地へいつ到着するかに基づいて全目的地をソートしてみましょう。今回も、これによりデータベースに対し1回のクエリしか実行されません。In addition, we can use new subquery features added to the query builder's orderBy
function to sort all destinations based on when the last flight arrived at that destination. Again, this may be done while executing a single query against the database:
return Destination::orderByDesc(
Flight::select('arrived_at')
->whereColumn('destination_id', 'destinations.id')
->orderBy('arrived_at', 'desc')
->limit(1)
)->get();
Laravel UILaravel UI
以前のバージョンのLaravelでは通常フロントエンドを提供していましたが、laravel/ui
Composerパッケージとして分離されました。これにより、フレームワーク本体より独立し、ファーストパーティのUIスカフォールドとして開発できるようになり、バージョニングも分けることができました。この変更の結果、デフォルトのフレームワークスカフォールドにはBootstrapやVueのコードが無くなり、make:auth
コマンドも同様にフレームワークから分離しました。The frontend scaffolding typically provided with previous releases of Laravel has been extracted into a laravel/ui
Composer package. This allows the first-party UI scaffolding to be developed and versioned separately from the primary framework. As a result of this change, no Bootstrap or Vue code is present in default framework scaffolding, and the make:auth
command has been extracted from the framework as well.
以前のLaravelリリースで提供していたVue/Bootstrapのスカフォールドに戻すには、laravel/ui
パッケージをインストールし、ui
Artisanコマンドを使用してフロントエンドスカフォールドをインストールします。In order to restore the traditional Vue / Bootstrap scaffolding present in previous releases of Laravel, you may install the laravel/ui
package and use the ui
Artisan command to install the frontend scaffolding:
composer require laravel/ui "^1.0" --dev
php artisan ui vue --auth