Are we still doing breaking changes in minor releases?

[thecodingdude]

So back in January I created issue #22833 wondering about the state of releases since many of them contained breaking changes.

Now since the release of 5.7 it seems the situation still hasn't improved. For example, in the 5.5 changelog we can see 5.5.43 has a change which states:

"BREAKING CHANGE: This change is known to have broken many applications."

Now, excuse me if I am being stupid here, but on Laravel's own website, it says:

Minor releases should never contain breaking changes.

The worst part is that this was only reverted 32 days later, after people had already upgraded and then had to revert those changes back to the old way. I cannot understand how/why this was ever accepted into a minor release when you clearly state breaking changes should never occur in minor releases.

Notice the 'never' in bold right there. However, in 5.5.40 we saw:

Revert breaking changes in ManagesLoops (#23681)

In 5.7.11:

Reverted filesystem changes which were done in #26010 (#26231)

In 5.7.8:

Revert of "html string support in translator" (e626ab3)

5.7.5:

Revert of "Remove Hash::check() for password verification" (2e78bf4)

My advice to people using this framework: don't upgrade minor versions, if you do things will randomly break, and a revert could be sent in after a month causing another breaking change after people had updated the framework, adapted to the breaking change and then had to revert those changes again.

Completely amateur and taylorotwell clearly does not care about 'breaking the user'. Maybe he needs a chat with Linus Torvalds.

[driesvints]

Minor releases should never contain breaking changes.

You're right. They shouldn't contain breaking changes. Unfortunately with such a large user base, edge cases will happen and things will slip in. When we're notified about those we do our best to revert those changes back and undo any wrong-doings. Sometimes this means that some time can creep in between the released breaking change and the fix.

Software development can be hard and by no means we intentionally want to break people's systems and apps. Software without bugs doesn't exists and is a myth. But we do our utmost best to keep these breaking changes to a minimum.

Completely amateur and taylorotwell clearly does not care about 'breaking the user'.

This couldn't be further from the truth. If all you're going to do is complain then please refrain from opening up issues. Use https://github.com/laravel/ideas if you want to propose a new release schedule and have a civilized discussion about it.

[thecodingdude]

@driesvints thanks for closing the issue and completely removing the chance for meaningful discourse. I admit I come across strongly only because I reported this in January and we're still seeing the same thing release after release.

and by no means we intentionally want to break people's systems and apps.

Yet you didn't address why the changelog has, in capital letters: "BREAKING CHANGE". How those words ever made it into a changelog for a minor LTS release is beyond me, then it was reverted after 32 days...

This was quite clearly, quite obviously intentional.

Software without bugs doesn't exists and is a myth.

We're not talking about bugs here, which are understandable, but people making PR's without realizing the impact they have on actual end users and applications.

Instead, you bury your head in the sand, pretend the issue doesn't exist (or more obviously, you don't care) rather than trying to figure a viable medium, such as what I proposed before: RC's or betas like most semver applications.

If Taylor cared, he'd stop shipping as often and actually test his releases, but as it stands, we get reverts every 3 or so releases.

And so it will continue. I have no doubt I'll be back for 5.10 or 6.3 and the same merge-oops-it-broke-revert system you guys have going will still be in effect.

[devcircus]

A few things to note. The "issues" for this repository is for reporting bugs. The laravel/ideas repo is for these discussions. This is why the issue was closed.

Secondly, you make some good points, but as a long time user of other large frameworks, breaking changes slip through sometimes, then get reverted.

Last, you should never update composer dependencies on a production project without fully vetting in a dev environment. Even patch, now called "minor", releases can have occasional breaking changes with regard to bug-fixing and security. Blindly running composer update without checking the changelog or "releases" page, is a recipe for disaster. If the changelog isn't clear, look at the actual commits. If your app is that important, you should at least scan every change that is made to the code base before using.

Even so, there could be more time available for PRs to be vetted by the community to help recognize breaking changes before the code is pushed.

[mfn]

Some of the unfortunate breaking changes could have easily been avoided.

Or, at least, the filesystem change break. When I first saw the PR it had alarm signs all over it yet this was done on 5.7 (and merged and reverted, etc.), rather on 5.8.

For my taste, way too much things are "changed" in minor version. Except changes to tests, I think half of that stuff should go in 5.8 or master.

But understandably, contributors are eager to get their stuff out and in again on their project due to the rapid release and this attracts contributors.

But here we've good/strong react from the other side, off-putting/discouraging.

A fun little Epiphany I just had because I commented on #26334 (comment) : people go berserk totally strong on all the fiddle formatting rules, yet breaking changes rather easily creep into releases… :|

[thecodingdude]

@mfn they don't care otherwise they would implement changes to ensure breaking changes are impossible (RC's and betas for example). Guess it's easier to merge and revert users be damned.

Shame but it is what it is, they're not good at taking criticism that hurts their egos, especially Taylor who seemingly can do no wrong...