Hacker News Reader

Comment by elmigranto | Hacker News Reader

I'm so out of the loop… Feels like a week ago everyone talked about how cool and performant v2 will be when it's finally out of the beta and officially ready for production, and now there is v4 release.

What's going on with versions?

View on HN

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

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

16 will be skipped for...no reason what so ever.

They should just name with a year. So in 2018 you'd know that Angular 2017 is so last year…

There is also AngularDart, which has forked and isn't following the same numbering scheme:

https://webdev.dartlang.org/angular

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

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.

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?

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.

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"?

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.

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.

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.

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.

All of the Angular modules were 2.x.x with exception to the router, which was version 3.x.x.

So to keep all of them at the same major version, they pushed everything to version 4.

Also, the jump from AngularJS (1) to Angular 2 was drastically different. Going from 2 to 4 however is much less significant in terms of breaking changes.

You won't have to relearn hardly anything if you already know 2.

SEMVER - Semantic Versioning - http://semver.org/

Not exactly semver either, Angular 4 is backward compatible with 2.x.x. Following semver would mean it should continue to be in 2 series

It makes breaking changes that might break some users. That is following semver. Semver doesn't follow backward compatibility in the major number, it follows potential breaking changes that will impact downstream consumers.

Aka when in doubt, increment leftmost, also we won't tell you wether we did a complete conceptual overhaul or just found a corner case that is provably incompatible. And I really thought it would be good.

It is explained in the first sentence of the article.

semver

Reply on news.ycombinator.com