I thought this was some kind of joke... until I realized they skipped v3. But still, v5 already? Or did I just get used to Bootstrap 4 being in Alpha for years?
4 -> 5 included some new cool features but was a smooth upgrade. 6 is coming out in March and then a new "major version" is scheduled every 6 months.
This is common for end-user apps but feels very weird for developer libraries and frameworks.
We are used to X.Y.Z releases where X are "major rewrite", Y are significant updates, and Z are bugfixes.
That said, Angular's new scheme could be technically correct strict "semantic versioning". In semver X.Y.Z, Z releases are supposed to be bugfixes with no feature additions, Y releases add features but with perfect backwards compatibility, and X releases introduce breaking changes. A backwards incompatible change, no matter how small and easy to adjust for, should be a major version bump according to semver.
It'd be interesting to see Angular join the React bandwagon and embrace codemods. React has broken compatibility several times (though you now get deprecation warnings on the final minor release before a breaking major) but Facebook has an internal policy that if React breaks compatibility, the React team has to fix the application code it breaks -- which has lead to every breaking change coming with codemods which can automate the necessary adjustments, making upgrades significantly smoother.
> 6 is coming out in March and then a new "major version" is scheduled every 6 months.
I work in a large corporation and they're still planning their transition to 1.5 and then to 2. I'm keeping up by building stuff in my off time, but trying to keep a fortune 200 corporation on a six month upgrade track? Not happening.
I've already heard rumblings from upper management of going back to some open source Java frameworks like Spring MVC, Vaadin or gulp Struts because of how fast they are releasing major versions and the time and cost of keeping up.
My fear is Angular will be regulated to startups, medium sized businesses or small autonomous business units within larger companies. When faced with a six month upgrade schedule, many larger organizations I fear are going to balk and just drop it in favor of something they are already comfortable with. . ergo my company wanting to go back to Java since 95% of everything built here is done with Java.
> I work in a large corporation and they're still planning their transition to 1.5 and then to 2.
Angular 1 -> 2 is an actual "major release". "Rewrite all your apps from scratch" major.
But starting from Angular 4, the "major version number changes" doesn't mean a major effort to update. There's a decent chance that 4 -> 5 -> 6 -> 7 etc will work without any code changes. But as long as there is a backwards-incompatible change, no matter how small and in how obscure submodule, it requires bumping the version number according to semver.
Most enterprise users will probably skip multiple versions between upgrades, just as they skip Ubuntu releases and Django releases and Rails releases and so on.
Joking aside, apart from semver another reason for the weird versioning in Angular is that it's a rather large collection of modules, especially if you include things like RxJS (which technically aren't exclusively part of Angular but affect APIs due to their widespread use). So it's fairly easy to get a semver major version bump because of an implementation detail you likely wouldn't care about but that breaks backwards compatibility with some older library in some way.
They changed to semantic versioning. From what I remember they intended to keep their development style of breaking backwards compatibility where convenient, though. The consequence is that you’ll regularly see major version bumps.
This is common for end-user apps but feels very weird for developer libraries and frameworks.
We are used to X.Y.Z releases where X are "major rewrite", Y are significant updates, and Z are bugfixes.
That said, Angular's new scheme could be technically correct strict "semantic versioning". In semver X.Y.Z, Z releases are supposed to be bugfixes with no feature additions, Y releases add features but with perfect backwards compatibility, and X releases introduce breaking changes. A backwards incompatible change, no matter how small and easy to adjust for, should be a major version bump according to semver.