TLDR; I would suggest either avoiding the RC tag, or using it more in line with norms for software development.
Over at 0.7.0 Release Changelog, Please?, it was pointed out that the changelog for firmware 0.7.0 was at https://github.com/particle-iot/firmware/blob/develop/CHANGELOG.md#070-see-additional-changelog-070-rc1--070-rc7. When I read through that, I began to understand my confusion about why 0.7.0 was in release candidate stage for so long. My conclusion is that Particle is not using the normal alpha–>beta–>release candidate naming convention.
The normal convention, as I understand it (and roughly mirrored on wikipedia) is that a new software version flows first from alpha, when new features are added; to beta, when there is a feature freeze and the ensemble is tested for bugs; and then finally to release candidate, when the devs think the release is done and all that is left is widespread testing for edge cases.
In that SRLC world, the RC stage is not when new features would be introduced or APIs deprecated. By RC stage-- because we typically expect little to no changes which would affect stability-- the message sent to the clients (us) is that it’s safe to begin testing for deployment across our entire fleet.
Personally, I would expect changes in the RC phase to be only bugs caught in widespread testing, e.g. tiny things like obscure Android interactions or fixing typos. Anything larger mean our testing results are no longer valid and we need to restart.
Not complaining about the release cycle or dev efforts, just observing that reusing the common nomenclature in this different way leads to confusion. For instance, to the casual observer it looks like it took Particle almost a year to get 0.7.0 out of RC stage. In reality, if we consider that RC started with 0.7.0-rc.6, then it was a reasonable 3 months to work the final edge case bugs out.
Do the devs agree? If not, what is the driving philosophy behind the naming convention used at Particle?