Hacker News new | past | comments | ask | show | jobs | submit login

Unfinished? How about never finished.

>Angular 2 is going to have breaking changes only every 6 months from now on. So the next one would be around February with Angular 3. Yes exactly, they’re also finally switching to semantic versioning which is a huge win in my opinion.

IMHO, breaking changes every six months is the recipe for an shitshow of an ecosystem.

http://juristr.com/blog/2016/09/ng2-released/




I don't think the idea of "planned" breaking changes every 6 months to be such a bad thing. A major release twice a year that you can upgrade to when you're good and ready.

Sounds like a way to prevent having to completely rewrite from the ground-up to keep up with the web a la angularjs.

I like React because it's a lot smaller but I totally see the advantages of Angular 2 and I kinda dig the major release cycle.


This release cycle is fine so long as you don't rely on anything but Angular 2.

As soon as you rely on packages that support Angular 2, the 'good and ready' argument breaks, since you can't start till all the packages you rely upon have already made the upgrade, and you can't take to long either, because you can't expect further work or fixes to be made to older versions of the packages.

12-month breaking changes, that would have made sense.


This makes the improper assumption that you're forced to upgrade. The code for Angular 2 will not evaporate when Angular 3 appears - at that point the choice to upgrade to the latest version is just that: a choice. You are free to wait until Angular 4 comes out before you adopt Angular 3 if you want to make sure the ecosystem around it is solidified.


I've been 'forced to upgrade' in the past by issues in dependencies that won't be fixed, with other dependencies not updated yet. It's a sticky wicket.

That said, breaking changes every six months seems to be commonplace in major open source packages. My initial reaction was 'OMG, now they want to repeat the Angular 2 debacle every 6 months?!?', which doesn't seem to be the case.


It sounds odd to me that an app would include packages that have dependencies on a framework. I'm having a hard time picturing an example, can you provide one?


I could have worded it better.

http://ngmodules.org


I'd like to point out that React has had breaking changes roughly 6 or less months apart also. This is a red herring of an argument, we see lots of successful libraries make breaking changes that often doing fine.

The scope of the breaking changes matter more, and that story has yet to be told.


> I'd like to point out that React has had breaking changes roughly 6 or less months apart

When? Can you cite an example? Keep in mind that for most breaking changes React typically goes to a deprecation warning for the duration of a major release instead of hard-breaking changes, so in reality you have roughly double the time between truly breaking releases, generally speaking.


Take a look at the changelog for breaking changes - they even timestamp it.

That is true about the deprecation, although some of the earmarked breaking changes have been quite painful too.

Hopefully the Angular team takes this route for planned breaking changes & apply engineering to ease compatibility.


That's a really good point, that I should have been aware of.

The more I reflect, the more I see this as about poor expectation management and messaging from the Angular team than an actual story.


Rails introduces some breaking changes now and then. The only troublesome upgrade was when they added the asset pipeline. Was that 3.0 or 3.2? If Angular is adding some features while deprecating others it won't be a big problem. If they break compatibility in a big way every six months, maybe it's not the place to be. High maintenance costs means that it's hard to sell to customers and even for internal projects one should evaluate if it's wise to allocate resources on rewriting the same code again and again. We'll see.


One other project comes to mind that also updates every six months: Ubuntu. Last I checked, their ecosystem was doing fairly well. I wouldn't consider Ubuntu "unfinished" unless we're talking about the state of all software everywhere.


Does Ubuntu ship breaking changes every six months? Do Ubuntu developers rely on other developers to keep their shared code updated and/or fork their repositories to support both new and old versions of the framework, every six months?


But, of course, Ubuntu also has LTS (Long Term Support) versions for people who don't want to upgrade frequently (you get security patches and the like but otherwise things stay stable for years).

http://tech.shantanugoel.com/2008/05/21/ubuntu-what-exactly-...


Ubuntu also has LTS releases for this exact reason.


Once the framework has actually shown some degree of maturity I don't think it would be unfair to ask the Angular team for an LTS version of Angular.


To update an app for the latest ubuntu, the worst case scenario is that you have to recompile.


Ok, now try to find at least one framework without breaking changes after initial release. Code should evolve, planned changes is a graceful evolution.


Breaking changes are to be expected. Breaking changes every six months are how you ruin an ecosystem.

React releases every 6 months or so, and puts deprecation warning on anything that is breaking in the next update, so you have a full year between any breaking features, and six months for everyone to update before they land.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: