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 < [email protected]> 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 >
