[
https://issues.apache.org/jira/browse/SOLR-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245479#comment-17245479
]
David Smiley commented on SOLR-14688:
-------------------------------------
I suspect there is something missing where the package manager needs to choose
_a supported_ version of a package _for the local node_ that may be different
for some other node since some other node may be running some newer/later Solr
version. Am I wrong? I think this is really important because Tomas points
out that Solr API changes that are binary incompatible (which will happen from
time to time) will then be _impossible_ to upgrade Solr. I don't think it's
reasonable for us to prevent binary incompatible changes; it's gonna happen.
Assuming it's not possible (yet), I'm not sure how much of a blocker this is
for package-ifying the contribs.
> First party package implementation design
> -----------------------------------------
>
> Key: SOLR-14688
> URL: https://issues.apache.org/jira/browse/SOLR-14688
> Project: Solr
> Issue Type: Improvement
> Reporter: Noble Paul
> Priority: Major
> Labels: package, packagemanager
>
> Here's the design document for first party packages:
> https://docs.google.com/document/d/1n7gB2JAdZhlJKFrCd4Txcw4HDkdk7hlULyAZBS-wXrE/edit?usp=sharing
> Put differently, this is about package-ifying our "contribs".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
