3 ms·

TL;DR - developer learns the meaning of Release Candidate or rather...does not: "To be fair, I have been using versions of the library that have thus far not b

TL;DR - developer learns the meaning of Release Candidate or rather...does not: "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.)

geldan 10y ago
You do so in a derogatory manner, but you bring up a decent point. This doesn't really seem to be a JavaScript issue so much as an open source issue.
- collyw 10y ago
  Using libraries in Perl and Python, they are generally a lot more finished that JavaScript in my experience.
BurningFrog 10y ago
Yeah, but a Release Candidate should be very close to what is finally released.
olavgg 10y ago
A release candidate is NOT supposed to have breaking changes.... its a friggin "release candidate". 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.
- dragonwriter 10y ago
  > A release candidate is NOT supposed to have breaking changes.... 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.
  - olavgg 10y ago
    No no and no. Breaking changes are not ok, not even slightly! 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.
  - ajmurmann 10y ago
    It's ok if the first RC had breaking changes but after that you should have only bug fixes between RC versions. It seems unusual that some breaking feature got for some reason left out from an earlier build that was considered a potential candidate for release.
lolc 10y ago
Complaining about API breakage in release candidates is justified. It happens far too often so people are desensitized to it. Maybe I'm old-fashioned but if you're still planning on changing the API, don't call it a release candidate.
- dragonwriter 10y ago
  > 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.
  - svachalek 10y ago
    "Things that may still change" is generally expected to be bug fixes. "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.
    - dragonwriter 10y ago
      > "RC" is not an excuse to flush semver down the toilet. 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.
  - lolc 10y ago
    Yes if you clarify a few wrinkles in the API from one RC to the next that is expected. 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.)

geldan 10y ago

You do so in a derogatory manner, but you bring up a decent point. This doesn't really seem to be a JavaScript issue so much as an open source issue.

collyw 10y ago
Using libraries in Perl and Python, they are generally a lot more finished that JavaScript in my experience.

BurningFrog 10y ago

Yeah, but a Release Candidate should be very close to what is finally released.

olavgg 10y ago

A release candidate is NOT supposed to have breaking changes.... its a friggin "release candidate". 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.

dragonwriter 10y ago
> A release candidate is NOT supposed to have breaking changes.... 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.
- olavgg 10y ago
  No no and no. Breaking changes are not ok, not even slightly! 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.
- ajmurmann 10y ago
  It's ok if the first RC had breaking changes but after that you should have only bug fixes between RC versions. It seems unusual that some breaking feature got for some reason left out from an earlier build that was considered a potential candidate for release.

lolc 10y ago

Complaining about API breakage in release candidates is justified. It happens far too often so people are desensitized to it. Maybe I'm old-fashioned but if you're still planning on changing the API, don't call it a release candidate.

dragonwriter 10y ago
> 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.
- svachalek 10y ago
  "Things that may still change" is generally expected to be bug fixes. "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.
  - dragonwriter 10y ago
    > "RC" is not an excuse to flush semver down the toilet. 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.
- lolc 10y ago
  Yes if you clarify a few wrinkles in the API from one RC to the next that is expected. 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.)