3 ms·

I don't think the idea of "planned" breaking changes every 6 months to be such a bad thing. A major release twice a year that you can upgrade to when you're goo

I don't think the idea of "planned" breaking changes every 6 months to be such a bad thing. A major release twice a year that you can upgrade to when you're good and ready. Sounds like a way to prevent having to completely rewrite from the ground-up to keep up with the web a la angularjs. I like React because it's a lot smaller but I totally see the advantages of Angular 2 and I kinda dig the major release cycle.

WalterSear 10y ago
This release cycle is fine so long as you don't rely on anything but Angular 2. As soon as you rely on packages that support Angular 2, the 'good and ready' argument breaks, since you can't start till all the packages you rely upon have already made the upgrade, and you can't take to long either, because you can't expect further work or fixes to be made to older versions of the packages. 12-month breaking changes, that would have made sense.
- seangrogg 10y ago
  This makes the improper assumption that you're forced to upgrade. The code for Angular 2 will not evaporate when Angular 3 appears - at that point the choice to upgrade to the latest version is just that: a choice. You are free to wait until Angular 4 comes out before you adopt Angular 3 if you want to make sure the ecosystem around it is solidified.
  - WalterSear 10y ago
    I've been 'forced to upgrade' in the past by issues in dependencies that won't be fixed, with other dependencies not updated yet. It's a sticky wicket. That said, breaking changes every six months seems to be commonplace in major open source packages. My initial reaction was 'OMG, now they want to repeat the Angular 2 debacle every 6 months?!?', which doesn't seem to be the case.
- slmyers 10y ago
  It sounds odd to me that an app would include packages that have dependencies on a framework. I'm having a hard time picturing an example, can you provide one?
  - WalterSear 10y ago
    I could have worded it better. http://ngmodules.org http://ngmodules.org

WalterSear 10y ago

This release cycle is fine so long as you don't rely on anything but Angular 2. As soon as you rely on packages that support Angular 2, the 'good and ready' argument breaks, since you can't start till all the packages you rely upon have already made the upgrade, and you can't take to long either, because you can't expect further work or fixes to be made to older versions of the packages. 12-month breaking changes, that would have made sense.

seangrogg 10y ago
This makes the improper assumption that you're forced to upgrade. The code for Angular 2 will not evaporate when Angular 3 appears - at that point the choice to upgrade to the latest version is just that: a choice. You are free to wait until Angular 4 comes out before you adopt Angular 3 if you want to make sure the ecosystem around it is solidified.
- WalterSear 10y ago
  I've been 'forced to upgrade' in the past by issues in dependencies that won't be fixed, with other dependencies not updated yet. It's a sticky wicket. That said, breaking changes every six months seems to be commonplace in major open source packages. My initial reaction was 'OMG, now they want to repeat the Angular 2 debacle every 6 months?!?', which doesn't seem to be the case.
slmyers 10y ago
It sounds odd to me that an app would include packages that have dependencies on a framework. I'm having a hard time picturing an example, can you provide one?
- WalterSear 10y ago
  I could have worded it better. http://ngmodules.org http://ngmodules.org