3 ms·

I never used Angular 2, but that sounds like the biggest issue is a release candidate that should have been called a beta or alpha release. I sometimes tend to

I never used Angular 2, but that sounds like the biggest issue is a release candidate that should have been called a beta or alpha release. I sometimes tend to try out beta releases when learning something new and interesting, but that does tend to backfire now and then when it's unstable enough that I can't tell if I'm doing something wrong, the framework is buggy or the documentation is simply outdated.

fixermark 10y ago
In general, if I understand correctly, "Release candidate" implies "unstable." The emphasis is on "Candidate," not "Release," i.e. "This bundle could end up being the final version, but it probably won't."
- ygra 10y ago
  It tends to imply that the API is stable, though. RCs tend to get a few bug fixes and other polishing, but not complete API overhauls.
- fabian2k 10y ago
  The old definition I learned is that it is a version that you think could be released, unless any major bugs appear that you don't know about yet. It's not something where you would expect major API changes. But those definitions have become much more fluid, and it's hard to find out which definitions everyone is using.
- kevindong 10y ago
  To me personally, "release candidate" implies "almost ready". After all, it is a candidate for release. In other words, it's released to the public for some final testing and bug fixes with no chance of additional features, API changes, etc. between the RC and the final release.
- tomnipotent 10y ago
  RC absolutely means non-breaking API changes. Bug fixes yes, but the API will be stable.
  - dragonwriter 10y ago
    It does not "absolutely" mean that. It certainly means API changes are not anticipated, and that there should be a very significant problem with an API to lead to an API change at that point; certainly one would hope that fundamental flaws in an API that make it unsuitable for release would be identified well before an RC. But its certainly possible to have reasons to make a breaking change from an RC (e.g. -- not necessarily relevant to a front-end framework, obviously -- a security vulnerability uncovered that reveals a critical flaw in the logical design, rather than implementation, of an API.)
    - Udik 10y ago
      > its certainly possible to have reasons to make a breaking change from an RC Sure. After which you issue a new RC, not the final release.
- jakub_g 10y ago
  "Release candidate" != "Release" but in my understanding "RC" is "almost finished, but we might have some bugs to fix before" Anyway my personal attitude is to keep away from alphas, betas, RCs and stable-from-yesterday. Applies to frameworks, operating systems and virtually everything, and each time I don't follow that rule, I regret.
dermotbrennan 10y ago
Release candidate to me means "We think this software is pretty much done. Does anybody in the community think otherwise?". You don't expect new features or breaking changes. That wasn't what happened during angular2 development. I started a project at around RC4. It's my own fault to some extent for doing that and not waiting or using angular1. I found that most of the core functionality like component annotations, ngInit, template syntax didn't change - although I wasnt trying to use the router or forms modules which did experience large changes over the 6 months. For me most of the pain was in keeping up with changes in the boilerplate stuff in the root of the app like main.ts, modules and and the same keeping up with recent big changes in angular-cli.
ascorbic 10y ago
Exactly this. I also just started using Angular 2. Unlike the OP I have a lot of web development experience, but this is the first time I've used Angular or Typescript. While I really like Angular and am really enjoying working with it, it is pretty exasperating to have loads of breaking changes between release candidates. That's not what release candidates are for. Forms are the worst. You're not supposed to introduce, deprecate and then remove whole modules between release candidates. There are even major, breaking changes between the final release candidate and the release version 2.0.0.

fixermark 10y ago

In general, if I understand correctly, "Release candidate" implies "unstable." The emphasis is on "Candidate," not "Release," i.e. "This bundle could end up being the final version, but it probably won't."

ygra 10y ago
It tends to imply that the API is stable, though. RCs tend to get a few bug fixes and other polishing, but not complete API overhauls.
fabian2k 10y ago
The old definition I learned is that it is a version that you think could be released, unless any major bugs appear that you don't know about yet. It's not something where you would expect major API changes. But those definitions have become much more fluid, and it's hard to find out which definitions everyone is using.
kevindong 10y ago
To me personally, "release candidate" implies "almost ready". After all, it is a candidate for release. In other words, it's released to the public for some final testing and bug fixes with no chance of additional features, API changes, etc. between the RC and the final release.
tomnipotent 10y ago
RC absolutely means non-breaking API changes. Bug fixes yes, but the API will be stable.
- dragonwriter 10y ago
  It does not "absolutely" mean that. It certainly means API changes are not anticipated, and that there should be a very significant problem with an API to lead to an API change at that point; certainly one would hope that fundamental flaws in an API that make it unsuitable for release would be identified well before an RC. But its certainly possible to have reasons to make a breaking change from an RC (e.g. -- not necessarily relevant to a front-end framework, obviously -- a security vulnerability uncovered that reveals a critical flaw in the logical design, rather than implementation, of an API.)
  - Udik 10y ago
    > its certainly possible to have reasons to make a breaking change from an RC Sure. After which you issue a new RC, not the final release.
jakub_g 10y ago
"Release candidate" != "Release" but in my understanding "RC" is "almost finished, but we might have some bugs to fix before" Anyway my personal attitude is to keep away from alphas, betas, RCs and stable-from-yesterday. Applies to frameworks, operating systems and virtually everything, and each time I don't follow that rule, I regret.

dermotbrennan 10y ago

Release candidate to me means "We think this software is pretty much done. Does anybody in the community think otherwise?". You don't expect new features or breaking changes. That wasn't what happened during angular2 development. I started a project at around RC4. It's my own fault to some extent for doing that and not waiting or using angular1. I found that most of the core functionality like component annotations, ngInit, template syntax didn't change - although I wasnt trying to use the router or forms modules which did experience large changes over the 6 months. For me most of the pain was in keeping up with changes in the boilerplate stuff in the root of the app like main.ts, modules and and the same keeping up with recent big changes in angular-cli.

ascorbic 10y ago

Exactly this. I also just started using Angular 2. Unlike the OP I have a lot of web development experience, but this is the first time I've used Angular or Typescript. While I really like Angular and am really enjoying working with it, it is pretty exasperating to have loads of breaking changes between release candidates. That's not what release candidates are for. Forms are the worst. You're not supposed to introduce, deprecate and then remove whole modules between release candidates. There are even major, breaking changes between the final release candidate and the release version 2.0.0.