On Wednesday, November 9, 2016, 7:23:09 AM CST, Harsha Chintalapani <[email protected]> wrote:> If we want users to upgrade to new version, the rolling upgrade is a major > decision factor. As a community, we need to look API updates or breaking > changes much more diligently. Within a major version, I agree. APIs should be as stable as possible within a version release.
> I agree to an extent we shouldn't limiting ourselves with rolling upgrade. > But having announced rolling-upgrade in 0.10 and then not supporting it in > 1.x and now in 2.x. In User's point of view, Storm is not rolling > upgradable although we shipped a release stating that rolling upgrade is > supported and in follow-up release we taken that off. The user would be correct. Storm would not be rolling-upgradable *between major versions.*I don't see how it's possible to develop and improve a project if it must remain perpetually backwards compatible, so I think it's necessary to reject compatibility as a *primary* goal. Eventually (hopefully) we'll arrive at an API that we're happy with that we don't feel like we need to change.Then we can claim rolling upgrades across major version numbers. > Does these API changes are critical and worth breaking rolling upgrade? My position is that we don't want to limit ourselves to "critical" API changes. This will stick us with an inferior API that we can't evolve.It's accepting the long-term pain of inconsistent API or old baggage to avoid the short-term pain of relaunching or updating topologies when you do a major version upgrade. Storm is not at the place in its life where it has stopped evolving, and I don't want to stifle its development.
