Releasing is not a Scrum event, and the end of the Sprint is not a release date. The Sprint boundary exists to create a rhythm of inspection and adaptation, and the decision about when finished work reaches the people who use it sits outside that rhythm entirely.
The Sprint Review is not a gate
Multiple Increments may be created within a Sprint. The sum of them is presented at the Sprint Review, which supports empiricism by giving stakeholders one occasion to inspect the whole and help decide what happens next. An Increment may still be delivered to stakeholders before the Sprint ends, and the Guide says in as many words that the Sprint Review should never be considered a gate to releasing value.
That sentence exists because teams kept inventing the gate anyway. Once the review becomes an approval step, value that was finished on the third day of the Sprint waits a fortnight for a meeting, and the organisation has added a queue to a framework designed to remove them.
Done is the only condition the framework sets
Work cannot be considered part of an Increment unless it meets the Definition of Done. That is the single constraint Scrum places on releasable work, and it is why the Definition of Done carries so much weight. Every other question about whether something should ship is a product decision or an organisational one rather than a rule of the framework.
An Increment therefore comes into being the moment an item meets the Definition of Done. A Sprint in which eleven items are finished has produced Increments along the way, and nothing requires them to be held together until the last one lands.
Releasing is an organisational decision
Whether a finished Increment actually reaches users depends on things Scrum does not govern. Regulatory approval, contractual dates, a partner's launch calendar and the state of the deployment pipeline all sit outside the framework, and a Product Owner working around those constraints is exercising product judgement rather than following a rule.
What matters in a scenario question is where the constraint really lives. If release waits because the team believes the Sprint Review must bless it first, that is a rule the team invented and Scrum contradicts it. If release waits because a regulator requires a certificate, that is the world, and the Product Owner's work is to order the backlog around it.
A rare release keeps the feedback loop long
Sprints can be short while the product still learns slowly. Where release stays a batched event that happens once a quarter, the loop that actually matters runs from an idea to evidence about that idea, and that loop is a quarter long no matter how briskly the Sprints tick past underneath it.
This is the reason a Done Increment and a released one are not the same thing, and the reason so much of a Product Owner's useful work happens outside the Scrum Team. Shortening the release cycle is usually a question of test automation, deployment tooling and the organisation's appetite for risk. None of that can be fixed by the Scrum Team alone, and all of it decides how fast the product is allowed to learn.