4 ms·
A release candidate is NOT supposed to have breaking changes.... its a friggin "release candidate". Projects with lot of breaking changes for minor releases sh
by 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 agoNo 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 agoIt'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.