> Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide.

I disagree. EmberJS is a great example of this philosophy done right. Major releases of Ember typically have no new features, they just break backwards compatibility in favor of more efficient ways to do things. This "sets the stage" for features that get added in minor releases. So when Ember releases a new major, you typically don't have to upgrade to it if you don't want the new features. But it's released so you can measure the level of effort as well as the impact the upgrade would have on your codebase. Contrast this with the way Ruby on Rails releases new major versions, with one giant release every couple years that either breaks compatibility, causes performance/cognitive issues, or some combination of the two.

In my opinion, major versions shouldn't have new features. The way Ember gets away with this is by sometimes releasing two versions simultaneously, a major "X.0.0" version for upgrading apps to measure the level of effort, and a minor "X.1.0" for new apps. Want to start a new app? Choose the first minor. Want to upgrade your old app? Choose the major.

I am not sure one can compare some JS framework with a language that was already 8 years old when JS as a language appeared. By the time JS was invented, there was already legacy perl code in production that needed to be maintained.

I don't see how that's relevant to software project management. The ways we release software and plan out roadmaps don't really have much to do with what language or framework the software was made in. Just because Ember is "some JS framework" doesn't mean it has no good ideas.

To me it's really not about whether it's a good idea or not. What works for an 8-year-old project that has always done it that way, may not work for a 33-year-old project which has never done it that way. The latest perl will run a huge chunk of the perl 1.0 test suite unmodified. That's a long history of backwards compatibility. This sudden change in focus and project-management may really backfire on them.

> Just because Ember is "some JS framework" doesn't mean it has no good ideas.

No, but time-scales matter. A good idea in a notoriously short lived ecosystem is not necessarily transferable to an environment in which one has to maintain 20 or 30 year old, mostly write-only code.

I don't quite understand this point. Perl has a major version, Perl 5. They want to offer a new major version, Perl 7, now. If Ember has already release a couple of new major versions, then why not learn from it? Maybe the Ember approach doesn't fit Perl, but without taking a look we won't know.

Also, based on the GP, it seems like Perl is planning something similar to what Ember has been doing: They are planning for Perl 7 to offer no new features, just change behavior. Then users can take their Perl 5 software and try it out with Perl 7 to see how much work it is to upgrade. Or they comb the source code to look for constructs that are deprecated.

Putting Perl aside for a bit, I don’t quite understand the benefit of the Ember strategy you described. If I have existing code that uses Ember x-1 when x.0.0 and x.1.0 are released, what is my reason for scoping the upgrade with x.0.0 vs x.1.0? If I don’t want to implement the new features, couldn’t I still update to x.1.0 without using anything new calls?

similar strategy is for Symfony in PHP for major versions and it works well. For example next major version 6.0 will have the same features as 5.4 version with removed BC layer (deprecations etc.). This allows for smoother upgrades. You just fix all deprecations and then You can upgrade major version without stress

That's so counter-intuitive and makes so much sense.

Not so much, as they only shifted semantics by -0.1. You cannot expect that your 2.0->x.0 will be as trivial as 1.9->2.0, because now ->2.1 is that hard upgrade that is called ->2.0 everywhere else.