3 ms·
He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake. A release candidate is a "release candidate", tha
by OskarS 10y ago
He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake. A release candidate is a "release candidate", that is to say "we're pretty sure we could release this whole thing right now, but we want to send it out to the community to make sure there are no catastrophic bugs we haven't noticed". In other words feature-complete, and with most of the kinks ironed out.
It's sheer insanity to make breaking changes or upgrade the dependencies between a release candidate and a final version. The upgrade from a release candidate to a final version should be the easiest upgrade in the world.
- plexicle 10y agoRCs should IDEALLY not have breaking changes. You can dice it up any way you want, but it wasn't a final build and there were obviously some rough edges. Angular 2 is final now and they've committed to no more breaking changes until the next major build (at least 6 months away). If s/he started learning with it today, then ~90% of what s/he was complaining about in this post wouldn't have been a thing. That was my only point.
- Udik 10y agoNot that I find the debate particularly productive, but "there will be no breaking changes" doesn't mean "final", it usually means (at most) release candidate. Or even beta. While "it works but we might still introduce breaking changes" is not a release candidate but maybe a technology preview.
- dkarapetyan 10y agoShe.
- OskarS 10y agoApologies to the article writer, i didn't notice and shouldn't have assumed.
- Aldo_MX 10y agoHe didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake Quoted for emphasis. Release Candidate means "The API is considered finished and we are stabilizing the code before our final release" Release Candidate doesn't mean "Beware! Don't you dare to build a real world application with our library since we will be breaking the API on a whim". If I wanted a dependency to have unpredictable breaking changes every minor version I would pick an Alpha version, not a Release Candidate one. Although to be fair, in my particular case it was my fault, seeing "Breaking Changes" in the changelog of a Release Candidate was a red flag I decided to ignore.