Projects with lot of breaking changes for minor releases should raise red flags, so steer away! Instead of wasting valuable time being bleeding edge, take a deep breath, turn your focus 180 degrees and say to yourself: I think will check it out in 5 years. There are a lot of other great, stable and mature web frameworks out there.
A release candidate isn't a release, and the release may have breaking changes from the RC, and obviously an RC of anything that would be a semver major release may have breaking changes from the previous actual release. So, in either direction, an RC may have breaking changes.
Ideally, the last RC should not have breaking changes between it and the actual release, but we wouldn't need a "candidate" if we knew things would be ideal.
It's not acceptable after an alpha release, It's especially not acceptable after a beta release. And it is offensive against developers to have breaking changes from the first release candidate and onwards.
Even for major releases, breaking changes is a VERY BAD thing. But sometimes it is unfortunately unavoidable.
Maybe I'm old-fashioned but if you're still planning on changing the API, don't call it a release candidate.
If you are planning on changing anything it shouldn't be a release candidate.
OTOH, the reason for the "candidate" part of "release candidate" is that things may still change from the plan.
"RC" is not an excuse to flush semver down the toilet. If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.
That's true. Then again, an RC in semver is a prerelease version and "A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version." (SemVer 2.0.0, para. 9)
Breaking changes from an RC isn't flushing semver down the toilet, its fairly explicitly permitted in the semver spec.
> If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.
No, if anywhere before the 2.0 release, including in any prerelease version in the 2.0 line (even an RC) you discover the need for a breaking change, that's fine per SemVer, and the major release that comes out of resolving those issues will still be 2.0.
If you have a bunch of active, unmerged, and API-breaking branches where you're not sure which one is going to make it into the release, don't call it a release candidate because you're planning to change the API. (I don't know whether this was the case with Angular, I just assume it after reading the rant.)
"To be fair, I have been using versions of the library that have thus far not been officially released. Maybe, you say, it’s my fault for trying to download and use a version of the library that is still in alpha/beta/release candidate and expecting it to work and be relatively easy to use. Perhaps you are right. But, considering the fact that hundreds of thousands of developers are already using Angular 2, we should ask ourselves the question: is it responsible to release libraries that are still very much a work in progress?"
They told you it was an RC, but now that a lot of people have started using it, you want them to no longer treat it as an RC. (And like a true whiner who likely will never contribute a single line of code, you want this all for free, of course.)