Ok, let me explain: it’s going to be Angular 4.0
angularjs.blogspot.com
angularjs.blogspot.com
It's much more reasonable though: they're committed to using Semver, so even a minor breaking change (like upgrading Typescript) will bump the version number. So they're expecting the version numbers not to matter as much anymore, similar to how you no longer think of the version number of Chrome or Firefox too often.
And so they are asking the community to just call it "Angular", not "Angular 1", "Angular 2" and "Angular 4". I do feel that this will make it harder to search for information, documentation or libraries specifically related Angular 1 though, if Angular 2+ is now just going to be called "Angular", much like all the Angular 1 specific stuff.
I was thinking twice as big ; D
(e.g., see TeX version numbering)
That's contradictory.
Once you introduce breaking changes, you require people to update, and old code may not work on new systems.
Then you can't just say "Angular" like you can't say "Python" or "C/C++"
The OP suggested to make an "evergreen" Angular, like an evergreen Chrome. My point is that you can't do that if you introduce breaking changes, because "this will work in C (and just upgrade to a new version if you don't have it)" doesn't work anymore.
Obviously making small breaking changes shouldn't require renaming your language (so PHP4 is still PHP, even though it broke quite a lot of old files relying on register_globals)
While it's slightly confusing given there is a clear divide between versions 1 and 2, it makes sense going forward to use these names.
Also, technically, there was a name change between v1 and v2, from "AngularJS" to "Angular".
still, I'm glad I moved to vue.
I cannot imagine working on a software project where I'd want to plan out four distinct breaking change updates. I simply cannot prognosticate my needs that well, nor chessmaster so deeply that I wouldn't just do it in one bigger change. If they're anything like me, that means they're committing to inducing the hassle _without even knowing what the payoff is_!
Or do you think they should not have done any breaking change at all?
On the other hand, the assumptions people have about the changes between Python 2 and 3 are probably bigger than they really are. I've started writing new code in P3 the last two years or so, and the only thing that still stumbles me from time to time is the parentheses around the `print` method.
This is an issue because many platforms and products shipped with some python2 scripts. So a developer trying to use python3 needed to start by setting up a mixed environment on their own.
Ruby could get away with crap like that because it wasn't widely used outside of Rails before rvm/rbenv was common.
Setting up python3 as the default python could break certain Linux distros.
Even today MacOS ships with python 2.7 as the default.
Python 3 fixed it, along with some other less drastic changes. Despite a gradual and ever ongoing migration to python 3 by every major library (http://py3readiness.org/ https://python3wos.appspot.com/), a lot of HN posters love to talk about how they'll never use python 3.
The secret is: no one cares. People still use java 1.4.2 and that hasn't impeded Java.
Python 3 was a large and backwards capability breaking change that required people to learn some minor new behaviors when writing code, but it has been and will continue to be the future.
Did they really ?. If they did they would focus on API stability instead of breaking changes. Moving to semver is an issue when a product didn't use semver at first place.
I want them to succeed but I also want to be able to pickup a framework I didn't use for a year without having to relearn its API.
Their 6 month release cycle is also very smart and allows for planning. I know that I'm only ever going to need to fix things once every 6 months when updating the library (if I do choose to update it) which seems pretty good to me.
Angular 1 and Angular 2+ are in essence completely different frameworks.
The "Angular" team should have picked a different name for their post-Angular 1 project.
The vibrant ecosystem of custom directives, etc., that surrounded Angular 1 must NOT be confused with the Angular 2+ project just so that everything can be "one big happy Angular".
"How can you not choose Angular? It's backed by Google and it's been around longer than both Ember and React."
Or, semver should start to update its major version every 4 months, perhaps Angular devs will understand what the term JavaScript fatigue means.
Sometimes there's a breaking change we need to work through (often in the plugin ecosystem with stuff like bell for oauth integration), but usually the major changes aren't too painful to transition through.
It's still nice to use semver and know what to expect. You just have to get acclimatized to having very large major version numbers. I mean, Chrome is up to version what, 55?
This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved. '''
Having a calendar of the breaking changes already planned like explain in the video seems dubious.
And about Chrome, Chrome is an implementation not a spec, Angular is both an implementation and a spec.
Do you really want a JavaScript 55 ?
So if they keep on track, JavaScript 55 will be here in 2055. ;)
Perhaps they do it because of job security?
If you hate anything, it should be Angular for they decide when they are going to introduce incompatible changes.
We lock all package versions now negating the benefits of semver.
Let's say you have N small projects, each of which gets a major version bump once every two years. Now, combine them into a single umbrella project. If you have 24 of them and they don't coordinate, you'll end up bumping the major version once a month (on average), even though the code didn't really change any more than before.
To somewhat improve on this, you can coordinate release dates, and you get a regular major version bump, the times when it's always true that some things changed, even though most things didn't. Either way, the version bump itself doesn't tell you as much compared to having separate projects.
I mean, there's a rather huge rift (i.e. TypeScript, tooling, etc) between Angular 1 and 2, but this might not be the case for future consecutive major versions.
Isn't that, well, all of them..?
Could the computer world follow automotive and use dates? 2017 Mustang? (As I type, I remember that Apple does this. Late 2013 MacBook Pro).
Maybe mix dates with semver? Angular 2017.1.2.9
I do think it fits well with "evergreen" software like Angular.
I can run HL1 on Windows 10 but my 5-months code for Angular is outdated.
Please, Angular team, be more pragmatic.
Isn't angular for "enterprise-large-project" that requires stable-API and such?
just use either React or Vuejs
Calling it just angular with multiple version changes makes it difficult to search for angular 1 lib/docs which is fully different framework and was/is also called angular
Angular takes semantic versioning seriously, and while they will not be doing a 1 -> 2 size change, they will need to increase the major version soon (Typescript upgrade, etc.)
They will also align the npm versions of the core packages. @angular/router is at 3.3, so the next available major version is 4.
Angular versioning gets even more screwed up. It's ok though because it's javascript.