4 ms·

"Angular 1" is now known as Angular.js and is effectively at the end of its line. Angular 2+ is now simply Angular. All new releases follow a naming of version

"Angular 1" is now known as Angular.js and is effectively at the end of its line. Angular 2+ is now simply Angular. All new releases follow a naming of version X.Y.Z where X indicates breaking changes, Y non-breaking new features, and Z is bug fixes. Version 3 is being skipped over due to poor naming of the related Angular Router lib. http://angularjs.blogspot.com/2016/12/ok-let-me-explain-its-going-to-be.html http://angularjs.blogspot.com/2016/12/ok-let-me-explain-its-...

wernercd 10y ago
Damn... I was really hoping for Angular 16 next year...
- chiefalchemist 10y ago
  16 will be skipped for...no reason what so ever.
- rimliu 10y ago
  They should just name with a year. So in 2018 you'd know that Angular 2017 is so last year…
skybrian 10y ago
There is also AngularDart, which has forked and isn't following the same numbering scheme: https://webdev.dartlang.org/angular https://webdev.dartlang.org/angular
cheapsteak 10y ago
It seems that lockstep versioning makes semantic versioning less meaningful A major version bump for a module could signal a breaking change, or it could just be due to the packages it's locked to having had a breaking change
- humanrebar 10y ago
  A breaking change in your dependencies is a breaking change for you. If it weren't, minor version upgrades would cause you to pull in incompatible dependencies. This is why keeping your dependency list as tiny as possible is imperative.
  - mikewhy 10y ago
    Wait, I'm confused. Say I'm the author of a library. Some of my dependencies had breaking changes, but they didn't affect the users of my library, as it's handled in some method. Should that be a new major version of the library?
    - humanrebar 10y ago
      The sensible default answer with no context is: bump your major version as well. The more nuanced answer is that it depends on your packaging system and your language runtime. If either cannot handle more than one minor version of a dependency at the same time, you need to bump a major version. The problem is that the code that uses your library might also indirectly be using that dependency, but pinned to a different major version. This means that the application is broken even though the breaking changes aren't used by your library. To illustrate: apple-1.0 => banana-1.0 => carrot-1.0 => broccoli-1.0 => carrot-1.0 Say, as the maintainer of banana-1.0 want bug fixes in carrot-2.0, so you pull it in and bump your minor version. And then an application updates it dependencies. apple-1.1 => banana-1.1 => carrot-2.0 => broccoli-1.3 => carrot-1.1 In some, though not many, systems, you can pull in two versions as if they were different libraries. But in almost all, you get a dependency conflict and apple will be broken. Even if you can juggle two dependencies of the same library, you need to make sure there wouldn't be any logic changes that would break the system or even corrupt data (!). Anyway, it's simpler to be conservative and bump the major version. Yes, that can be a pain. But, again, it's good to keep your dependency list small or at least very boring to keep that pain to a minimum.
batat 10y ago
I thought upgrading from 2.x.x to 4.x.x shold break something according to SemVer. So why "it's backwards compatible with 2.x.x"?
- a-kojeve 10y ago
  I think the distinction is that a breaking API change breaks some of your code, a backward incompatible change breaks your entire codebase -- i.e., fix a few method signatures vs refactor your entire codebase.
- tomku 10y ago
  You've got it backwards. If you make a breaking change, semver requires you to bump the version number. There is absolutely nothing in the semver spec requiring you to make a breaking change when you bump the version number. The spec only specifies one of those directions, you're free to bump the major version for any change if you feel like it. Doing so would make your versioning scheme much less useful, but it's not actually breaking the semver rules.
  - WorldMaker 10y ago
    There's also nothing in the spec that stops you from taking a very conservative view of what constitutes a "breaking change". There are many types of changes that may be backwards compatible and you're mostly sure shouldn't break anything, but you want to signal that it might just in case. What constitutes a breaking change that warrants a major version bump is a subjective problem left to project maintainers.
    - tomku 10y ago
      Totally agree, and I think that's what's going on with Angular. Bumping the major version for a set of modules also communicates that you really should be using 4.x of all these modules together rather than mixing and matching with 2.x, even if some subset of them are technically backwards compatible.

wernercd 10y ago

Damn... I was really hoping for Angular 16 next year...

chiefalchemist 10y ago
16 will be skipped for...no reason what so ever.
rimliu 10y ago
They should just name with a year. So in 2018 you'd know that Angular 2017 is so last year…

skybrian 10y ago

There is also AngularDart, which has forked and isn't following the same numbering scheme: https://webdev.dartlang.org/angular https://webdev.dartlang.org/angular

cheapsteak 10y ago

It seems that lockstep versioning makes semantic versioning less meaningful A major version bump for a module could signal a breaking change, or it could just be due to the packages it's locked to having had a breaking change

humanrebar 10y ago
A breaking change in your dependencies is a breaking change for you. If it weren't, minor version upgrades would cause you to pull in incompatible dependencies. This is why keeping your dependency list as tiny as possible is imperative.
- mikewhy 10y ago
  Wait, I'm confused. Say I'm the author of a library. Some of my dependencies had breaking changes, but they didn't affect the users of my library, as it's handled in some method. Should that be a new major version of the library?
  - humanrebar 10y ago
    The sensible default answer with no context is: bump your major version as well. The more nuanced answer is that it depends on your packaging system and your language runtime. If either cannot handle more than one minor version of a dependency at the same time, you need to bump a major version. The problem is that the code that uses your library might also indirectly be using that dependency, but pinned to a different major version. This means that the application is broken even though the breaking changes aren't used by your library. To illustrate: apple-1.0 => banana-1.0 => carrot-1.0 => broccoli-1.0 => carrot-1.0 Say, as the maintainer of banana-1.0 want bug fixes in carrot-2.0, so you pull it in and bump your minor version. And then an application updates it dependencies. apple-1.1 => banana-1.1 => carrot-2.0 => broccoli-1.3 => carrot-1.1 In some, though not many, systems, you can pull in two versions as if they were different libraries. But in almost all, you get a dependency conflict and apple will be broken. Even if you can juggle two dependencies of the same library, you need to make sure there wouldn't be any logic changes that would break the system or even corrupt data (!). Anyway, it's simpler to be conservative and bump the major version. Yes, that can be a pain. But, again, it's good to keep your dependency list small or at least very boring to keep that pain to a minimum.

batat 10y ago

I thought upgrading from 2.x.x to 4.x.x shold break something according to SemVer. So why "it's backwards compatible with 2.x.x"?

a-kojeve 10y ago
I think the distinction is that a breaking API change breaks some of your code, a backward incompatible change breaks your entire codebase -- i.e., fix a few method signatures vs refactor your entire codebase.
tomku 10y ago
You've got it backwards. If you make a breaking change, semver requires you to bump the version number. There is absolutely nothing in the semver spec requiring you to make a breaking change when you bump the version number. The spec only specifies one of those directions, you're free to bump the major version for any change if you feel like it. Doing so would make your versioning scheme much less useful, but it's not actually breaking the semver rules.
- WorldMaker 10y ago
  There's also nothing in the spec that stops you from taking a very conservative view of what constitutes a "breaking change". There are many types of changes that may be backwards compatible and you're mostly sure shouldn't break anything, but you want to signal that it might just in case. What constitutes a breaking change that warrants a major version bump is a subjective problem left to project maintainers.
  - tomku 10y ago
    Totally agree, and I think that's what's going on with Angular. Bumping the major version for a set of modules also communicates that you really should be using 4.x of all these modules together rather than mixing and matching with 2.x, even if some subset of them are technically backwards compatible.