
Ok, let me explain: it’s going to be Angular 4.0 - theodorejb
http://angularjs.blogspot.com/2016/12/ok-let-me-explain-its-going-to-be.html
======
joneil
The title "Angular 4 will be the next version of Angular" had me ready to
believe they were announcing another breaking change as big as Angular 1 ->
Angular 2. (The blog post's title is "Ok... let me explain: it's going to be
Angular 4").

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.

~~~
cbdfghh
>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.

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++"

~~~
klodolph
I know what you mean but it's kind of ridiculous to say that "you can't say
'Python'". There's a reason why the project name doesn't change just because
you bumped the major version number.

~~~
cbdfghh
>There's a reason why the project name doesn't change just because you bumped
the major version number.

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)

------
hawkice
The real story here is the seemingly casual way they've decided to start
treating breaking changes. Deprecation periods are more polite than not having
them, but saying that users need to be constantly using the most up to date
version to get information about future support, and then introducing breaking
changes into the current version more regularly, seems like a step in the
wrong direction. Projects who lose a lot of community engagement due to
breaking changes should be the ones who understand how much of a self-
inflicted hassle that is best.

~~~
tribby
while I don't disagree with your premise, I think a more generous conclusion
is that the angular team has learned from the 1->2 disaster, and has decided
to focus on the long term, even if that means causing more headaches in the
short term.

still, I'm glad I moved to vue.

~~~
hawkice
But my concern is about how they are scheduling breaking changes to occur so
frequently, and almost two years in advance! Why induce that kind of headache
over and over so regularly that the short-term issues become a long-term
software maintenance burden?

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_!

~~~
maxpolun
I think they're just being very strict about what counts as breaking. They
gave the example of upgrading the typescript compiler they use as breaking.

~~~
sooheon
There's a Korean saying for this, it goes something like: "when the navel
outgrows the belly".

------
a-guest
Angular 1 is NOT Angular 2 or higher.

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".

~~~
FloNeu
But as i understand there is a workable update-path ( also automated client?
Experiences anyone ) - and as far as i am just starting working with angular2
the general concepts are still pretty close to angular1. I stopped developing
ng1 about two years ago, because i ran into concerns i couldn't fix -
ultimatly breaking my use-case. But all of them are fixed in ng2, so i will
give it another run ( with high hopes )...

------
uncle_joe
I think i officially hate semver. I seems a good idea at first. But updating
the major version of Angular every 6 months, will not help us.

Or, semver should start to update its major version every 4 months, perhaps
Angular devs will understand what the term JavaScript fatigue means.

~~~
mmgutz
Semver has bitten us several times with node packages. All most of us care
about is whether a release is backwards compatible with the package we
developed against. There should be one rule: if it's the same major version it
is compatible.

We lock all package versions now negating the benefits of semver.

~~~
majewsky
Exactly. I always say that, if I ever design my own programming language with
a central package repository, I will build the repo such that it downright
refuses to publish minor version updates that break the API (or patch updates
that change the API).

------
miqkt
It'll be interesting to see how this change in versioning might impact
recruitment for developers to service different versions of Angular projects.
I guess this goes especially for recruiters who don't really know (or care
about) Semver.

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.

~~~
bshimmin
_I guess this goes especially for recruiters who don 't really know (or care
about) Semver._

Isn't that, well, all of them..?

------
saghm
First Windows, then Node, and now Angular. I worry that soon we'll completely
lose the ability to count properly.

~~~
appleiigs
XBox to XBox 360 to Xbox One.

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

~~~
pfranz
I'm pretty sure Windows (and Apple with iWork) ditched yearly versioning for
public-facing version numbers because if they didn't have a yearly release
everything looked out of date.

I do think it fits well with "evergreen" software like Angular.

------
SteveNuts
Personally I can't wait until Angular 7 is out by Q1 2017

~~~
bulkan
but don't worry about version numbers it's just angular.

------
EugeneOZ
Too often they bring breaking changes. I hoped after stable release they will
stop breaking things every two weeks or so, as it was in alpha, but looks like
they still don't understand that every breaking change stops development of
projects for 1-2 days and this time is not free. I want to write code to solve
business tasks, not just patching working code because of one more
imperfection they found.

I can run HL1 on Windows 10 but my 5-months code for Angular is outdated.

Please, Angular team, be more pragmatic.

~~~
67726e
Are you using a bleeding edge release? Why not pick a stable release and stick
with it?

~~~
EugeneOZ
No, I use stable release. It was released 3 months ago. It's too often for
breaking changes.

~~~
dcherman
I think his point was that you're not being forced to upgrade if your current
version is working for you. You don't have to be on the bleeding edge if that
isn't working out for your business.

~~~
EugeneOZ
Stable version is not bleeding edge. And if you don't upgrade on new versions,
you also mix bugfixes and price (complexity) of future upgrades just grows.

------
ben_jones
I write angular 1 and 2 at work, so I like angular, but isn't their a point
where the powers that be should stop rocking the boat? All my colleagues who
use other SPA frameworks really have their eye on the project's pitfalls when
they should at least keep up with its virtues.

------
ausjke
what a chaos, so not only the internal changes break everything, even the
version-numbers do it too, what's the next surprise?

Isn't angular for "enterprise-large-project" that requires stable-API and
such?

just use either React or Vuejs

~~~
oceanswave
Funny that you mention react as they went from .14 to 15 in April

~~~
based2
[https://facebook.github.io/react/blog/2016/02/19/new-
version...](https://facebook.github.io/react/blog/2016/02/19/new-versioning-
scheme.html)

[http://rc.vuejs.org/2016/04/27/announcing-2.0/](http://rc.vuejs.org/2016/04/27/announcing-2.0/)

[https://blog.dantup.com/2014/10/have-the-angular-team-
lost-t...](https://blog.dantup.com/2014/10/have-the-angular-team-lost-their-
marbles/)

------
wnevets
There were breaking changes going from 1.2 to 1.3, those weren't any better
than the possible breaking changes going from 2 to 4

------
eva1984
Next next is Angular 8? Neat

------
latchkey
Now I get to write 'Angular > 1' all the time.

------
m3kw9
Weren't people still trying to adapt to angular 3?

------
paulddraper
tl;dr

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.

------
ascotan
tl;dr

Angular versioning gets even more screwed up. It's ok though because it's
javascript.

~~~
tannhaeuser
Not even. It's Typescript.

