You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Ishan Chattopadhyaya <ic...@gmail.com> on 2020/10/01 08:24:52 UTC
Backward compatability handling across major versions
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
Re: Backward compatability handling across major versions
Posted by Noble Paul <no...@gmail.com>.
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 <ds...@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 <ic...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Backward compatability handling across major versions
Posted by David Smiley <ds...@apache.org>.
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 <
ichattopadhyaya@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
>
Re: Backward compatability handling across major versions
Posted by Ilan Ginzburg <il...@gmail.com>.
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 <no...@gmail.com> 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
> <ic...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Backward compatability handling across major versions
Posted by Noble Paul <no...@gmail.com>.
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
<ic...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org