Bleeding edge Angular

Are you doing either "bleeding" or "leading" edge Angular 2?

If you say yes as of recently (today is June 1, 2017) then I would have to question it.  Angular is now at version 4.x and the published release plan indicates another major release this year.  The plan says there should be major releases every 6 months or so.

Are you creating production apps?  I have to question the wisdom of that right now unless you either have a large set of dedicated Angular developers or maybe "a good number" of developers and a paid support plan with someone that can handle any issues with common 3rd party / open source components.

In the Npm/Angular ecosystem, generally you will only get a warning on version mismatches unless there is an incompatible API change.  The fact that something compiles doesn't mean it will work.

You take on a lot of risk either sticking with Angular 2 OR moving up to the current Angular release.  Sticking with Angular 2 leaves you little room for updating components which moved to Angular 4 as their official dependency.  You don't really know they will work unless you fully test things.  You do have nearly 100% code coverage in your tests right?    Of course, you can move to Angular 4 but there is always a chance that some component you use is stuck with Angular 2 and has some issue with Angular 4+.  Neither situation is good.  Angular 4 is supposed to be mostly compatible with 2 so maybe moving to Angular 4 is a safer bet?  I tossed my dice in that direction - if for no other reason, at least the components I use that moved to Angular 4 have a better chance of working (and/or gaining features I need) and if not - updated versions would be for version 4.  I suspect that many/most open source / 3rd party components will not be back patching for Angular 2  even if needed (unless you have a support contract of some sort). This is just my experience with a few items I used recently - I don't see any work going into Angular 2 compatible versions now that Angular 4 is the official dependency.

So this basically means that we must try and keep up with current releases of most everything to reduce the risk of a component becoming incompatible with something.  Of course, you may have components that don't release often (or maybe aren't even maintained any longer) - in that case you may have to do your own maint work.  This isn't a great situation to be in.

I will say that with Angular 4 using semantic versioning, it is a step forward in maturity and if enough important 3rd party projects either use semantic versioning or will shortly then some common pain points should clear up a bit.  Right now though, I still fear that any version decision made still leads to a painful problem. Increases in the maturity and stability of the entire ecosystem takes time.  I see the start of those changes occurring though (an example from this week is npm version 5 which was just released) - those in charge do appear to listen and are trying to improve things.

Now if only Bootstrap 4 would hurry along to a release.Sigh. Too much change in too short of a time span sure does cause a lot of headaches.

[Edit 2017/6/11] Using Angular 4 in production may not be overly problematic in itself - it is more about the supporting libraries, frameworks and utilities which are changing quickly and in incompatible ways. This is turning into a bit of "guilt through association". Some work that was started with Bootstrap 4 (alpha) is turning into an increasingly large headache.  I should have backed out Bootstrap 4 and reworked it with Bootstrap 3. Someone recently mentioned a desire to merge some code bases which would turn into a lot of work and analysis - which project dependencies are carried forward?  Hoping we can delay any merge for a little while - hopefully after Bootstrap 4 gets to a production release. At that point, it should make sense to carry forward all the "release" versions of things I migrated to already and get off of various beta items in other projects as well (Webpack 2 being the big one).