Windows remains perpetually backwards compatible. Even to the point that windows ships with older broken versions of internal libraries so if it detects specific software and load up the old version as needed.
Mac usually provides an upgrade path and will allow apps using up to date APIs from the previous version of the OS to run on the new version unchanged. But if you are using a deprecated API you have to change before the next version is released of you will be in trouble, and even some non-deprecated APIs can change at a moments notice. The Linux kernel maintains strict compatibility with user space like windows, which is why docker can work, but with break kernel modules without too much concern. The GNU user space, however breaks binary compatibility between releases all the time, but maintains source compatibility (just recompile). Hadoop will break things between major releases but not between minor releases. There is no guarantee of a rolling upgrade between major releases. Which is partly why they are just starting to move towards 3.x and have multiple different flavors of 2.x lines alive. And then there is guava where they just don't care. There are pros and cons to all of these. I thought initially that we had agreed on a model like Hadoop, although truthfully I don't think we ever formalized any of that, and that is why I started this chain. I really see value, however, in the Mac model. And since I can maintain compatibility, but it is a little painful to do so, I will try to do that. Right now, honestly, I think 2.x could be a rolling upgrade from 1.x, so I will try to maintain that. We may hit a feature where it just will not be possible to do that, but we should discuss that when it happens. - Bobby On Thursday, November 10, 2016, 3:06:41 AM CST, 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.
