16 ms·

Ok, let me explain: it’s going to be Angular 4.0

93 points by theodorejb 10y ago

hawkice 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        There's a Korean saying for this, it goes something like: "when the navel outgrows the belly".
  - MrLeap 10y ago
    This was the same philosophy behind python 3, released 8 years ago. Still amazes me how slow the shift from 2.* -> 3 has been.
    - kylec 10y ago
      Python 2 to Python 3 is the preeminent example of how NOT to transition a software platform.
      - ars 10y ago
        Can you post a summary of what they did wrong, and what they should/could have done different? Or do you think they should not have done any breaking change at all?
        huskyr 10y ago
        They probably should have followed the PHP release pattern, which introduces breaking changes to the language in a more gradual way, over a couple of releases, instead of doing it in one big go. 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.
        klodolph 10y ago
        Honestly, the string / unicode fix is the biggest thing that breaks Python 2 scripts in Python 3, and Python 3 is so much better for having made the change. I don't see how that particular change could have been pushed through without breaking everything--and yes, I am counting the miscellaneous fixes they pushed through afterwards like bringing back u''.
        tannhaeuser 10y ago
        They didn't do anything wrong. But users are left with massive Python 2 codebases (certbot/letsencrypt, caldav-server/twisted, blender, maybe some OpenStack stuff and probably much more) that are very useful/essential to their users. What do you expect mere users to do? Invest massively in porting (adding test cases in the process where there don't exist any)? They will rather keep Python 2 around forever.
  - camus2 10y ago
    > 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. 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.
- asher_ 10y ago
  How is using semver casual? In AngularJS they introduced breaking changes a number of times, without a major version bump. Using semver makes it really clear, and since they are being so strict about it, there is greater confidence when updating to non-major releases. I think this is great. 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.
joneil 10y ago
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.
- FLGMwt 10y ago
  > 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. I was thinking twice as big ; D
  - wernercd 10y ago
    They are moving at an exponential rate... before you know, we'll be at Angular 16.
    - joneil 10y ago
      Does Semver's spec take into account integer overflows?
- pfooti 10y ago
  to be fair, I was hoping they were going powers-of-two on their releases. There's something very knuthian about that versioning scheme. (e.g., see TeX version numbering)
- cbdfghh 10y ago
  >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++"
paulddraper 10y ago
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.
uncle_joe 10y ago
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.
- pfooti 10y ago
  I dunno. I use hapijs at my day job (and am .. happy .. with it). They're on like version 16.0 so far, but I tend to only actually bump my own installed version every now and again. We basically update if there's a bug we need addressing or whenever it's time to update all our dependencies. 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?
  - uncle_joe 10y ago
    Here is an except of the FAQ of semver ''' If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly? 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 ?
    - the_duke 10y ago
      ECMAScript in their eternal wisdom have decided to do a yearly release of the spec with incremental updates. So if they keep on track, JavaScript 55 will be here in 2055. ;)
m3kw9 10y ago
Weren't people still trying to adapt to angular 3?
EugeneOZ 10y ago
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 10y ago
  Are you using a bleeding edge release? Why not pick a stable release and stick with it?
  - EugeneOZ 10y ago
    No, I use stable release. It was released 3 months ago. It's too often for breaking changes.
    - dcherman 10y ago
      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 10y ago
        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.
SteveNuts 10y ago
Personally I can't wait until Angular 7 is out by Q1 2017
- bulkan 10y ago
  but don't worry about version numbers it's just angular.
  - deleted 10y ago
    [deleted]
miqkt 10y ago
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 10y ago
  I guess this goes especially for recruiters who don't really know (or care about) Semver. Isn't that, well, all of them..?
ausjke 10y ago
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
- STRiDEX 10y ago
  The internal changes include upgrading from typescript 1.8 to typescript 2.x. WHAT A CHAOS
- oceanswave 10y ago
  Funny that you mention react as they went from .14 to 15 in April
  - manquer 10y ago
    Well that was just numbering . The API itself didn't change that much. 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
  - based2 10y ago
    https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html https://facebook.github.io/react/blog/2016/02/19/new-version... 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-their-marbles/ https://blog.dantup.com/2014/10/have-the-angular-team-lost-t...
ascotan 10y ago
tl;dr Angular versioning gets even more screwed up. It's ok though because it's javascript.
- tannhaeuser 10y ago
  Not even. It's Typescript.
wnevets 10y ago
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
ben_jones 10y ago
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.
eva1984 10y ago
Next next is Angular 8? Neat
saghm 10y ago
First Windows, then Node, and now Angular. I worry that soon we'll completely lose the ability to count properly.
- appleiigs 10y ago
  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 10y ago
    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.
latchkey 10y ago
Now I get to write 'Angular > 1' all the time.
a-guest 10y ago
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 10y ago
  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 )...
- droidist2 10y ago
  They probably didn't want to feed into Google's reputation for abandoning their stuff, so they kept the same name to make it seem like a continuation of the framework that's been around since 2010. It gives the illusion of stability, even though it's actually the opposite. "How can you not choose Angular? It's backed by Google and it's been around longer than both Ember and React."

93 points by theodorejb 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      There's a Korean saying for this, it goes something like: "when the navel outgrows the belly".
- MrLeap 10y ago
  This was the same philosophy behind python 3, released 8 years ago. Still amazes me how slow the shift from 2.* -> 3 has been.
  - kylec 10y ago
    Python 2 to Python 3 is the preeminent example of how NOT to transition a software platform.
    - ars 10y ago
      Can you post a summary of what they did wrong, and what they should/could have done different? Or do you think they should not have done any breaking change at all?
      - huskyr 10y ago
        They probably should have followed the PHP release pattern, which introduces breaking changes to the language in a more gradual way, over a couple of releases, instead of doing it in one big go. 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.
        klodolph 10y ago
        Honestly, the string / unicode fix is the biggest thing that breaks Python 2 scripts in Python 3, and Python 3 is so much better for having made the change. I don't see how that particular change could have been pushed through without breaking everything--and yes, I am counting the miscellaneous fixes they pushed through afterwards like bringing back u''.
      - tannhaeuser 10y ago
        They didn't do anything wrong. But users are left with massive Python 2 codebases (certbot/letsencrypt, caldav-server/twisted, blender, maybe some OpenStack stuff and probably much more) that are very useful/essential to their users. What do you expect mere users to do? Invest massively in porting (adding test cases in the process where there don't exist any)? They will rather keep Python 2 around forever.
- camus2 10y ago
  > 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. 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.
asher_ 10y ago
How is using semver casual? In AngularJS they introduced breaking changes a number of times, without a major version bump. Using semver makes it really clear, and since they are being so strict about it, there is greater confidence when updating to non-major releases. I think this is great. 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.

joneil 10y ago

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.

FLGMwt 10y ago
> 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. I was thinking twice as big ; D
- wernercd 10y ago
  They are moving at an exponential rate... before you know, we'll be at Angular 16.
  - joneil 10y ago
    Does Semver's spec take into account integer overflows?
pfooti 10y ago
to be fair, I was hoping they were going powers-of-two on their releases. There's something very knuthian about that versioning scheme. (e.g., see TeX version numbering)
cbdfghh 10y ago
>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++"

paulddraper 10y ago

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.

uncle_joe 10y ago

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.

pfooti 10y ago
I dunno. I use hapijs at my day job (and am .. happy .. with it). They're on like version 16.0 so far, but I tend to only actually bump my own installed version every now and again. We basically update if there's a bug we need addressing or whenever it's time to update all our dependencies. 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?
- uncle_joe 10y ago
  Here is an except of the FAQ of semver ''' If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly? 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 ?
  - the_duke 10y ago
    ECMAScript in their eternal wisdom have decided to do a yearly release of the spec with incremental updates. So if they keep on track, JavaScript 55 will be here in 2055. ;)

m3kw9 10y ago

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

EugeneOZ 10y ago

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 10y ago
Are you using a bleeding edge release? Why not pick a stable release and stick with it?
- EugeneOZ 10y ago
  No, I use stable release. It was released 3 months ago. It's too often for breaking changes.
  - dcherman 10y ago
    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 10y ago
      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.

SteveNuts 10y ago

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

bulkan 10y ago
but don't worry about version numbers it's just angular.
- deleted 10y ago
  [deleted]

miqkt 10y ago

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 10y ago
I guess this goes especially for recruiters who don't really know (or care about) Semver. Isn't that, well, all of them..?

ausjke 10y ago

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

STRiDEX 10y ago
The internal changes include upgrading from typescript 1.8 to typescript 2.x. WHAT A CHAOS
oceanswave 10y ago
Funny that you mention react as they went from .14 to 15 in April
- manquer 10y ago
  Well that was just numbering . The API itself didn't change that much. 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
- based2 10y ago
  https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html https://facebook.github.io/react/blog/2016/02/19/new-version... 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-their-marbles/ https://blog.dantup.com/2014/10/have-the-angular-team-lost-t...

ascotan 10y ago

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

tannhaeuser 10y ago
Not even. It's Typescript.

wnevets 10y ago

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

ben_jones 10y ago

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.

eva1984 10y ago

Next next is Angular 8? Neat

saghm 10y ago

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

appleiigs 10y ago
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 10y ago
  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.

latchkey 10y ago

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

a-guest 10y ago

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 10y ago
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 )...
droidist2 10y ago
They probably didn't want to feed into Google's reputation for abandoning their stuff, so they kept the same name to make it seem like a continuation of the framework that's been around since 2010. It gives the illusion of stability, even though it's actually the opposite. "How can you not choose Angular? It's backed by Google and it's been around longer than both Ember and React."