The title "Angular 4 will be the next version of Angular" had me ready to believe they were announcing another breaking change as big as Angular 1 -> Angular 2. (The blog post's title is "Ok... let me explain: it's going to be Angular 4").
It's much more reasonable though: they're committed to using Semver, so even a minor breaking change (like upgrading Typescript) will bump the version number. So they're expecting the version numbers not to matter as much anymore, similar to how you no longer think of the version number of Chrome or Firefox too often.
And so they are asking the community to just call it "Angular", not "Angular 1", "Angular 2" and "Angular 4". I do feel that this will make it harder to search for information, documentation or libraries specifically related Angular 1 though, if Angular 2+ is now just going to be called "Angular", much like all the Angular 1 specific stuff.
>It's much more reasonable though: they're committed to using Semver, so even a minor breaking change (like upgrading Typescript) will bump the version number. So they're expecting the version numbers not to matter as much anymore, similar to how you no longer think of the version number of Chrome or Firefox too often.
That's contradictory.
Once you introduce breaking changes, you require people to update, and old code may not work on new systems.
Then you can't just say "Angular" like you can't say "Python" or "C/C++"
I know what you mean but it's kind of ridiculous to say that "you can't say 'Python'". There's a reason why the project name doesn't change just because you bumped the major version number.
>There's a reason why the project name doesn't change just because you bumped the major version number.
The OP suggested to make an "evergreen" Angular, like an evergreen Chrome. My point is that you can't do that if you introduce breaking changes, because "this will work in C (and just upgrade to a new version if you don't have it)" doesn't work anymore.
Obviously making small breaking changes shouldn't require renaming your language (so PHP4 is still PHP, even though it broke quite a lot of old files relying on register_globals)
You can't call both Angular 1.x and Angular 2.x just Angular because they are pretty much different frameworks. I'm sure Smv is not meant to be used that way.
> The title "Angular 4 will be the next version of Angular" had me ready to believe they were announcing another breaking change as big as Angular 1 -> Angular 2.
This talk [1] by Rich Hickey seems more pertinent than ever. It's a contrarian stance on semver (which, almost as much as vc itself, is lauded as "the Right way" among developers). He definitely challenged my beliefs, it's likely to be worth your time too.
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.
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.
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_!
> 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.
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.
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''.
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.
I wouldn't be surprised if Blender was dragging their feet moving to Python 3 just because all of the major 3d software tools have embedded Pythons that are only recently reaching 2.7 (Maya, Nuke, Houdini, Mari, etc).
One big problem they had was that they felt that hosting multiple Python versions on a system was a sysadmin problem, not a language runtime problem.
This is an issue because many platforms and products shipped with some python2 scripts. So a developer trying to use python3 needed to start by setting up a mixed environment on their own.
Ruby could get away with crap like that because it wasn't widely used outside of Rails before rvm/rbenv was common.
Setting up python3 as the default python could break certain Linux distros.
Even today MacOS ships with python 2.7 as the default.
As someone not familiar with the situation, could you please give a brief of what happened with the Python 2 to 3 transition and why did it turn out so bad?
Python 2 had an inherent flaw with character encoding. While passing data around, strings and bytes were treated as the same thing, until they weren't the same thing, at which point your software broke in horrible and unexpected ways.
Python 3 fixed it, along with some other less drastic changes. Despite a gradual and ever ongoing migration to python 3 by every major library (http://py3readiness.org/https://python3wos.appspot.com/), a lot of HN posters love to talk about how they'll never use python 3.
The secret is: no one cares. People still use java 1.4.2 and that hasn't impeded Java.
Python 3 was a large and backwards capability breaking change that required people to learn some minor new behaviors when writing code, but it has been and will continue to be the future.
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.
Angular 1 and Angular 2+ are in essence completely different frameworks.
The "Angular" team should have picked a different name for their post-Angular 1 project.
The vibrant ecosystem of custom directives, etc., that surrounded Angular 1 must NOT be confused with the Angular 2+ project just so that everything can be "one big happy Angular".
But as i understand there is a workable update-path ( also automated client? Experiences anyone ) - and as far as i am just starting working with angular2 the general concepts are still pretty close to angular1. I stopped developing ng1 about two years ago, because i ran into concerns i couldn't fix - ultimatly breaking my use-case. But all of them are fixed in ng2, so i will give it another run ( with high hopes )...
They probably didn't want to feed into Google's reputation for abandoning their stuff, so they kept the same name to make it seem like a continuation of the framework that's been around since 2010. It gives the illusion of stability, even though it's actually the opposite.
"How can you not choose Angular? It's backed by Google and it's been around longer than both Ember and React."
I don't think the problem is with semver. That has a very clear goal of describing MAJOR.MINOR.PATCH changes where MAJOR is a version increase when you make incompatible API changes. semver is merely describing the results of your changes.
If you hate anything, it should be Angular for they decide when they are going to introduce incompatible changes.
Semver (or really, the concept of a single unified version number) makes it difficult to compare small versus large projects. Large projects have less information in the version number.
Let's say you have N small projects, each of which gets a major version bump once every two years. Now, combine them into a single umbrella project. If you have 24 of them and they don't coordinate, you'll end up bumping the major version once a month (on average), even though the code didn't really change any more than before.
To somewhat improve on this, you can coordinate release dates, and you get a regular major version bump, the times when it's always true that some things changed, even though most things didn't. Either way, the version bump itself doesn't tell you as much compared to having separate projects.
Semver has bitten us several times with node packages. All most of us care about is whether a release is backwards compatible with the package we developed against. There should be one rule: if it's the same major version it is compatible.
We lock all package versions now negating the benefits of semver.
Exactly. I always say that, if I ever design my own programming language with a central package repository, I will build the repo such that it downright refuses to publish minor version updates that break the API (or patch updates that change the API).
I dunno. I use hapijs at my day job (and am .. happy .. with it). They're on like version 16.0 so far, but I tend to only actually bump my own installed version every now and again. We basically update if there's a bug we need addressing or whenever it's time to update all our dependencies.
Sometimes there's a breaking change we need to work through (often in the plugin ecosystem with stuff like bell for oauth integration), but usually the major changes aren't too painful to transition through.
It's still nice to use semver and know what to expect. You just have to get acclimatized to having very large major version numbers. I mean, Chrome is up to version what, 55?
Here is an except of the FAQ of semver
'''
If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly?
This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.
'''
Having a calendar of the breaking changes already planned like explain in the video seems dubious.
And about Chrome, Chrome is an implementation not a spec, Angular is both an implementation and a spec.
Yeah, I don't understand it either. Why do they setup themselves (and their users) to that kind of "march of progress"? They should target features that are in real demand rather than regularly put out what they have.
It'll be interesting to see how this change in versioning might impact recruitment for developers to service different versions of Angular projects. I guess this goes especially for recruiters who don't really know (or care about) Semver.
I mean, there's a rather huge rift (i.e. TypeScript, tooling, etc) between Angular 1 and 2, but this might not be the case for future consecutive major versions.
I'm pretty sure Windows (and Apple with iWork) ditched yearly versioning for public-facing version numbers because if they didn't have a yearly release everything looked out of date.
I do think it fits well with "evergreen" software like Angular.
Too often they bring breaking changes. I hoped after stable release they will stop breaking things every two weeks or so, as it was in alpha, but looks like they still don't understand that every breaking change stops development of projects for 1-2 days and this time is not free. I want to write code to solve business tasks, not just patching working code because of one more imperfection they found.
I can run HL1 on Windows 10 but my 5-months code for Angular is outdated.
I think his point was that you're not being forced to upgrade if your current version is working for you. You don't have to be on the bleeding edge if that isn't working out for your business.
Stable version is not bleeding edge. And if you don't upgrade on new versions, you also mix bugfixes and price (complexity) of future upgrades just grows.
I write angular 1 and 2 at work, so I like angular, but isn't their a point where the powers that be should stop rocking the boat? All my colleagues who use other SPA frameworks really have their eye on the project's pitfalls when they should at least keep up with its virtues.
Well that was just numbering . The API itself didn't change that much.
Calling it just angular with multiple version changes makes it difficult to search for angular 1 lib/docs which is fully different framework and was/is also called angular
Angular takes semantic versioning seriously, and while they will not be doing a 1 -> 2 size change, they will need to increase the major version soon (Typescript upgrade, etc.)
They will also align the npm versions of the core packages. @angular/router is at 3.3, so the next available major version is 4.
It's much more reasonable though: they're committed to using Semver, so even a minor breaking change (like upgrading Typescript) will bump the version number. So they're expecting the version numbers not to matter as much anymore, similar to how you no longer think of the version number of Chrome or Firefox too often.
And so they are asking the community to just call it "Angular", not "Angular 1", "Angular 2" and "Angular 4". I do feel that this will make it harder to search for information, documentation or libraries specifically related Angular 1 though, if Angular 2+ is now just going to be called "Angular", much like all the Angular 1 specific stuff.