Skip to content

Clarify the docs about the Package Manager#2147

Merged
mkhludnev merged 1 commit into
apache:mainfrom
AndreyBozhko:package-manager-docs
Dec 12, 2023
Merged

Clarify the docs about the Package Manager#2147
mkhludnev merged 1 commit into
apache:mainfrom
AndreyBozhko:package-manager-docs

Conversation

@AndreyBozhko
Copy link
Copy Markdown
Contributor

Description

Update the Reference Guide to clarify the actual behavior of Package Manager, - specifically, how it processes the version strings of packages.

Tests

NA

Checklist

Please review the following and check all that apply:

  • I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
  • I have created a Jira issue and added the issue ID to my pull request title.
  • I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
  • I have developed this patch against the main branch.
  • I have run ./gradlew check.
  • I have added tests for my changes.
  • I have added documentation for the Reference Guide

@mkhludnev mkhludnev merged commit 3331e6d into apache:main Dec 12, 2023
Versions are sorted by their numeric value and the highest is the latest.
Versions are sorted by their values in lexicographic order, and the largest string is considered to be the latest.

CAUTION: Lexicographic order for version strings means that for a package with versions *1.2.0*, *1.9.0*, *1.11.0*,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

REally? Can we please get a JIRA to fix this ;-).

The default version used in any collection is always the latest.
However, setting a per-collection property in `params.json` ensures that the versions are always fixed irrespective of the new versions added.
However, setting a per-collection property in `params.json` ensures that the collection uses the same
package version (i.e., version *2.0*), irrespective of any versions larger than *2.0* that may be added to Solr
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should say "later" or "more recent" than, versus "larger"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@epugh I thought of that, but felt that it could be misleading - because, for example, the current package version in Solr could be 2.11.0, and then the user uploads 2.9.0 (which isn't more recent semantically, but is "larger" lexicographically).

So without the params.json, the collection will be "upgraded" to use 2.9.0, - but if the version 2.11.0 is pinned, it will be used regardless of how the Solr compares the version strings.

mkhludnev pushed a commit to mkhludnev/solr that referenced this pull request Dec 12, 2023
Co-authored-by: Andrey Bozhko <abozhko@apple.com>
mkhludnev added a commit that referenced this pull request Dec 12, 2023
Co-authored-by: Andrey Bozhko <andybozhko@gmail.com>
Co-authored-by: Andrey Bozhko <abozhko@apple.com>
@AndreyBozhko AndreyBozhko deleted the package-manager-docs branch December 12, 2023 23:15
mkhludnev added a commit that referenced this pull request Dec 13, 2023
mkhludnev added a commit that referenced this pull request Dec 13, 2023
mkhludnev added a commit to mkhludnev/solr that referenced this pull request Dec 13, 2023
mkhludnev added a commit that referenced this pull request Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants