4 ms·

That seems like a small update compared to v4. Wouldn't it be better to brand it as a minor version and provide backwards compatibility with deprecation warning

by kamac 9y ago

That seems like a small update compared to v4. Wouldn't it be better to brand it as a minor version and provide backwards compatibility with deprecation warning where Promises were added?

arghwhat 9y ago
If following semver style: Major updates include backwards incompatible changes. Minor updates include new functionality but no backwards incompatible changes. Patch updates include no new functionality. There are backwards incompatible changes, so it has to be a major bump.
- thinkloop 9y ago
  OP was suggesting not to have included backwards-incompatible changes, using deprecation warnings instead and branding it as a minor upgrade
  - coldtea 9y ago
    Hence OP was suggesting not following the semantic versioning model. Why would they do that? To have extra work and to have to carry deprecated garbage and compatibility ports for a few releases more, instead of making a clean new version? Those that need compatibility can stick with 4 until they're ready.
    - icebraining 9y ago
      The semantic versioning model just says how you should update your version if you break compatibility, not that you can't avoid breaking compatibility. In fact, they suggest the opposite: "Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API." https://semver.org/#how-should-i-handle-deprecating-functionality https://semver.org/#how-should-i-handle-deprecating-function...
  - arghwhat 9y ago
    Either my memory fails me, or the comment was edited... I don't recall responding to a comment that mentioned using deprecation warnings instead. :/
    - kamac 9y ago
      Sorry, I edited it right after posting it. Didn't think somebody could answer that fast :p
travellingprog 9y ago
Regularly occurring major versions, with only a small amount of changes, has actually kind of become seen as best practice in the JavaScript community. React, Node, Angular and a ton of other popular tools now release a major version update every year or 6 months. The reasoning is that by taking small, backward-incompatible steps, then developers are more likely to make the effort to install the latest update. To understand the problems the community is trying to avoid, one only needs to go back to 2015-2016, when Angular 2 was released. At the time, AngularJS (aka Angular 1) was extremely hot; it had in record time become THE framework for any front-end developer to learn, and it looked set to dominate the landscape for years. And then, Angular 2 came out and it had a TON of changes. The learning curve of some elements of Angular 2 was very high for the average developer (TypeScript, reactive programming). And worst of all, the "migration path" from AngularJS to Angular 2 essentially amounted to a rewrite of your front-end application. Most never bothered updating their app, and most devs moved away from Angular, especially when React was released. All of that AngularJS experience that we accumulated became "outdated" in the span of about a year.
- stupidcar 9y ago
  Sorry, but this is a rewriting of history and the present facts, and I can't let it go unchallenged. React was first released in 2013, whereas Angular (2) was first released in 2016. React was already a very popular and rapidly growing framework by that point, so the idea that people adopted it simply because of Angular 2 is clearly false. And while the migration process from Angular 1 to 2 was painful, it's simply untrue to say that nobody bothered, or that every AngularJS developer moved away. If you look at a source like https://hotframeworks.com/ https://hotframeworks.com/, which sources framework popularity data from GitHub and Stack Overflow, you can see that Angular has achieved a significant amount of adoption, and there are plenty of examples of people migrating successfully from 1 to 2+.
  - cbaleanu 9y ago
    Sorry but your facts are just wrong. Angular2 was announced in late 2014, just about the time when angular 1 was becoming mainstream used by big banks and the like. Look at Microsoft's blog from early 2015 announcing the use of typescript in Angular2. Linking some generic website does not make your comment less toxic and I would strongly suggest you get your facts right before posting stuff like that here.
ldiracdelta 9y ago
Semver is awesome. If the owner adheres to it, then it can be a very strong signal to the downstream users about whether they should be able to [probably] upgrade seamlessly vs possibly having to do some major rework. Also, if you see an adherent of semver bumping the major number all the time, you can choose whether you want to sign up for the churn on subsequent releases or not. Semver seems to encourage backwards compatibility. Not force, but encourage. There's a reason Microsoft and Intel worship backwards compatibility. Your downstream users love backwards compatibility.

by kamac 9y ago

That seems like a small update compared to v4. Wouldn't it be better to brand it as a minor version and provide backwards compatibility with deprecation warning where Promises were added?

arghwhat 9y ago

If following semver style: Major updates include backwards incompatible changes. Minor updates include new functionality but no backwards incompatible changes. Patch updates include no new functionality. There are backwards incompatible changes, so it has to be a major bump.

thinkloop 9y ago
OP was suggesting not to have included backwards-incompatible changes, using deprecation warnings instead and branding it as a minor upgrade
- coldtea 9y ago
  Hence OP was suggesting not following the semantic versioning model. Why would they do that? To have extra work and to have to carry deprecated garbage and compatibility ports for a few releases more, instead of making a clean new version? Those that need compatibility can stick with 4 until they're ready.
  - icebraining 9y ago
    The semantic versioning model just says how you should update your version if you break compatibility, not that you can't avoid breaking compatibility. In fact, they suggest the opposite: "Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API." https://semver.org/#how-should-i-handle-deprecating-functionality https://semver.org/#how-should-i-handle-deprecating-function...
- arghwhat 9y ago
  Either my memory fails me, or the comment was edited... I don't recall responding to a comment that mentioned using deprecation warnings instead. :/
  - kamac 9y ago
    Sorry, I edited it right after posting it. Didn't think somebody could answer that fast :p

travellingprog 9y ago

Regularly occurring major versions, with only a small amount of changes, has actually kind of become seen as best practice in the JavaScript community. React, Node, Angular and a ton of other popular tools now release a major version update every year or 6 months. The reasoning is that by taking small, backward-incompatible steps, then developers are more likely to make the effort to install the latest update. To understand the problems the community is trying to avoid, one only needs to go back to 2015-2016, when Angular 2 was released. At the time, AngularJS (aka Angular 1) was extremely hot; it had in record time become THE framework for any front-end developer to learn, and it looked set to dominate the landscape for years. And then, Angular 2 came out and it had a TON of changes. The learning curve of some elements of Angular 2 was very high for the average developer (TypeScript, reactive programming). And worst of all, the "migration path" from AngularJS to Angular 2 essentially amounted to a rewrite of your front-end application. Most never bothered updating their app, and most devs moved away from Angular, especially when React was released. All of that AngularJS experience that we accumulated became "outdated" in the span of about a year.

stupidcar 9y ago
Sorry, but this is a rewriting of history and the present facts, and I can't let it go unchallenged. React was first released in 2013, whereas Angular (2) was first released in 2016. React was already a very popular and rapidly growing framework by that point, so the idea that people adopted it simply because of Angular 2 is clearly false. And while the migration process from Angular 1 to 2 was painful, it's simply untrue to say that nobody bothered, or that every AngularJS developer moved away. If you look at a source like https://hotframeworks.com/ https://hotframeworks.com/, which sources framework popularity data from GitHub and Stack Overflow, you can see that Angular has achieved a significant amount of adoption, and there are plenty of examples of people migrating successfully from 1 to 2+.
- cbaleanu 9y ago
  Sorry but your facts are just wrong. Angular2 was announced in late 2014, just about the time when angular 1 was becoming mainstream used by big banks and the like. Look at Microsoft's blog from early 2015 announcing the use of typescript in Angular2. Linking some generic website does not make your comment less toxic and I would strongly suggest you get your facts right before posting stuff like that here.

ldiracdelta 9y ago

Semver is awesome. If the owner adheres to it, then it can be a very strong signal to the downstream users about whether they should be able to [probably] upgrade seamlessly vs possibly having to do some major rework. Also, if you see an adherent of semver bumping the major number all the time, you can choose whether you want to sign up for the churn on subsequent releases or not. Semver seems to encourage backwards compatibility. Not force, but encourage. There's a reason Microsoft and Intel worship backwards compatibility. Your downstream users love backwards compatibility.