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 <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
