In my opinion, when we really need to break backward compatibility (be it a change of API or of how features are made available, for example Autoscaling), I think the friendly way to do it is to introduce the new implementation first (co-existing with the old one!), deprecate but keep the old way of doing, and after a few releases remove from the code the old way of doing.
This gives users time and freedom of how to manage their transition (and does not force a transition when upgrading to a specific version), with both the old and new ways of doing things available for a while. Sometimes this is not possible and we have to be less friendly to our users, but we should really try to limit these cases as much as possible (implies discussions and exploring available options). Ilan On Thu, Oct 1, 2020 at 10:30 AM Noble Paul <[email protected]> wrote: > > In fact I was shocked at the cavalier attitude with which backward > compatibility is broken. If we are going to make a backward > incompatible change > > There should be a JIRA with the proper discussions > > * What is the change? > * Why is the change important? > * What is the strategy for someone who does a rolling upgrade? > * Is it possible to avoid it? > * Can the change be done in a backward compatible way so that the > users are not inconvenienced > > On Thu, Oct 1, 2020 at 6:25 PM 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 > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
