See #20487 for the reasoning. Is there anything that broke for you?

@iltar mocking within a test. A BC is an objective thing and not a perspective of a single person or a group. Does it break existing code event tests => BC, the only exception is if some plays with reflection.

It was considered a BC break, but it was already not working for inheritance, so they've decided to make it impossible to extend. It will save developers a lot of headache and time just to find out it doesn't work.

For your tests, see: https://github.com/symfony/symfony/pull/20487/files#diff-e8a7dfc3f0826c43961bd686470a714bR356

@iltar thanks for help

I have no reason to change my opinion about BC, cause its a boolean decision, not something that is to be discussed, as for example things like code quality.

Its painful to see, that i was right about my guess about the reaction on this issue. Made the same experience in most of issues i opened.

While BC breaks are either yes or no, that doesn't mean that the developer experience has to suffer on it.

Yes - Symfony has a policy about BC breaks.
Yes - This is a BC break.

However, this issue caused some hard to find and debug errors, which really gave developers problems. In this case I personally agree with the fact that it was made final as no production code would've worked. This is also preventing developers from wasting time and is worth more than preventing a BC break.

Yes - your test broke, but luckily it's only a test and it takes a few minutes to fix it at most. Honestly, I don't see the problem, life nor software development are black and white.

You are right, it's a BC break. Even if inheritance was broken in some cases, it could have been working enough for your use case.
We could have marked it @final for deprecating extending it at first. But then, we would have let other users use the buggy part.
Please do not believe that we are not open to discuss any of the changes we make. If you (or others) have suggestions for reducing the impact of the breaking change which is worth the hassle, we can always reconsider. That's always a case by case decision.
Thanks.

@linaori If it was a BC Break why symfony haven't release a new version?
In symfony docs: Also note that backward compatibility breaks are tolerated if they are required to fix a *security* issue.
This class has @internal tag - no!
Was it a security Issue - no!
Can I extend it and use without bugs - yes.

p.s. Symfony can bump up PATCH version instead of MINOR, there is no difference. New version Break current working code adding final modifier.

As this issue is close to 2 years old, I don't think it's worth discussing anything here. If there's still an issue related to this, you can create a new issue.

BC or not; would it be possible to make a ProgressBar-interface that can be mocked? Please?

@maartenderie as a workaround you can use an anonymous class:

        $progressBarMock = new class {
            public function start(): void
            {}
            public function advance(): void
            {}
            public function finish(): void
            {}
        };

        $outputStyleMock = $this->createMock(OutputStyle::class);
        $outputStyleMock
            ->expects($this->once())
            ->method('createProgressBar')
            ->willReturn($progressBarMock);

        $command->setOutput($outputStyleMock);