Why don't we start introducing protocol versions in thrift API. This way a old supervisor can still communicate by providing a older version and new nimbus can handle both protocols. API changes doesn't necessarily mean we've to break the older API. If the existing users doesn't have good upgrade path there will less uses on the new version. Critical API changes can still be possible by versioning the API. -Harsha
On Thu, Nov 10, 2016 at 7:06 AM Kyle Nusbaum <[email protected]> wrote: > 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. >
