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