Yes, we break backward compatibility all the time. Solr is a web service. Most users are only concerned about
* REST end points * configurations in ZK * index format Java API changes are not that critical. But, we still need to call them out. The case in point was a configuration file stored in ZK. With that change, it is IMPOSSIBLE to do a rolling upgrade. The only choice is to * Bring down the entire cluster * Run the scripts to do an upgrade * Pray everything comes back up We should minimize any change that will prevent people from doing rolling upgrades. If possible, our changes should be friendly to a rolling upgrade. All such changes MUST HAVE an associated ticket just to discuss the backward compatibility break. We should weigh in the impact of such changes on our users. On Thu, Oct 1, 2020 at 10:18 PM David Smiley <dsmi...@apache.org> wrote: > > Agreed that back-compat matters should not "sneak" into an issue that is not > about that. There are of course gray areas -- much of Solr core Java APIs > are public yet we don't need to treat everything with such burdensome care. > It takes experience and some subjectivity to know. The PR you point to is > very clear to me, as it's a web service API endpoint. > > We *can* break back-compat on a major release :-). But such discussion > deserves its own issue about breaking that compatibility. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Thu, Oct 1, 2020 at 4:25 AM Ishan Chattopadhyaya > <ichattopadhy...@gmail.com> wrote: >> >> Hi Devs, >> As per earlier discussions, we want to do a better job of handling major >> version upgrades, possibly support rolling upgrades wherever possible. This >> implies that we don't break backward compatibility without a strong reason >> and adequate discussion around it. >> >> Recently, there was a PR that attempted to sneak in a backward incompatible >> change to an endpoint for plugins (package management). This change was >> totally unrelated to the JIRA/PR and there was absolutely no discussion or >> even an attempt to address the upgrade strategy with that change. The >> attitude was a careless one, on the lines of we can break backward >> compatibility in a major release. >> https://github.com/apache/lucene-solr/pull/1758#discussion_r494134314 >> >> Do we have any consensus on whether we need a separate JIRA or broader >> discussion on any backward compatibility breaks? Or shall we let these >> changes be sneaked in, unless someone notices very carefully a few lines of >> changes in a 25 class PR? >> >> Looking for some suggestions here. >> Thanks and regards, >> Ishan -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
