[
https://issues.apache.org/jira/browse/SOLR-15902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474889#comment-17474889
]
Houston Putman commented on SOLR-15902:
---------------------------------------
This fails now because the PackageManager does not correctly vet the
SolrVersion constraints when auto-updating a package deployed as version:
{*}latest{*}.
Setup: An old version (1.0) that is valid with this version of solr is
installed and deployed, however a newer version (1.1) that does not support the
running solr version exists.
Successful Scenario: (Incorrect)
# Deploy the package tied to the *latest* version, however Solr still only
knows about 1.0, because you never installed 1.1. The component version will
still be 1.0.
# Install the package without a version. This will install 1.1, and
automatically deploy it because the deployed package is tied to **latest**.
# The component is now using 1.1, even though 1.1 does not support the current
running version of Solr.
Failure Scenario: (Correct)
# Install the package without a version. This will install 1.1, however the
deployed package is tied to 1.0, so it will not change when just installing a
new version.
# Deploy the package, updating to the **latest** version. This fails because
the latest version, 1.1 is not compatible with the running version of Solr.
This is why {{PackageManagerCLITest.testPackageManager}} sometimes succeeds and
sometimes fails, because there is a random gate that chooses either of the two
above scenarios.
> PackageManagerCLITest.testPackageManager fails on main
> ------------------------------------------------------
>
> Key: SOLR-15902
> URL: https://issues.apache.org/jira/browse/SOLR-15902
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Gus Heck
> Assignee: Houston Putman
> Priority: Major
> Fix For: 9.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The version for main has advanced, but this test contains a package with an
> upper version constraint of 9 and main has advanced to 10.0 It also contains
> two binary jar files containing classes with a fullstory package and no
> source code. There is a manifest.json, but there is also another copy baked
> into one of the jars. This needs to be cleaned up such that these jar files
> (containing packages to be installed during tests) can be rebuilt by a build
> target and are not checked in as binary jars. (with a .tmp ending). Also all
> classes run by the build should exist as source code. If the code for these
> classes is owned by Fullstory, they should be replaced with something owned
> by Apache.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
