10 ms·

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, bu

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

by hawkice 10y ago

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.