Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OF-2941: Improve Version comparison that involve SNAPSHOTs #2643

Merged

Conversation

guusdk
Copy link
Member

@guusdk guusdk commented Jan 3, 2025

For certain versions of plugins, Openfire incorrectly identifies that an update is available.

When Openfire has installed 10.1.7.3-SNAPSHOT it incorrectly identifies that version 10.1.7.2 is an update.

This seems to be caused by Openfire’s abuse of the 4th numeric value in a version. It was originally intended to be a classifier for the status (eg: ‘the second beta release’). When that 4th value is used as part of a four-digit version, things do not quite compare as expected.

To illustrate, compare these two scenarios. The numbers 3 and 2 are all stored in the same field, which gets interpreted differently.

  • 10.1.7 beta 3 is older than 10.1.7 release 2
  • 10.1.7.3-SNAPSHOT is expected to be newer than 10.1.7.2 (release).

Prior to this commit, Openfire did not flag that 10.1.7.3-SNAPSHOT is newer than 10.1.7.2, which was causing confusion.

In this commit, only the SNAPSHOT release status is now compared differently (as if the 4th value is part of the version string).

For certain versions of plugins, Openfire incorrectly identifies that an update is available.

When Openfire has installed `10.1.7.3-SNAPSHOT` it incorrectly identifies that version `10.1.7.2` is an update.

This seems to be caused by Openfire’s abuse of the 4th numeric value in a version. It was originally intended to be a classifier for the status (eg: ‘the second beta release’). When that 4th value is used as part of a four-digit version, things do not quite compare as expected.

To illustrate, compare these two scenarios. The numbers 3 and 2 are all stored in the same field, which gets interpreted differently.

- `10.1.7 beta 3` is older than `10.1.7 release 2`

- `10.1.7.3-SNAPSHOT` is expected to be newer than `10.1.7.2` (release).

Prior to this commit, Openfire did not flag that `10.1.7.3-SNAPSHOT` is newer than `10.1.7.2`, which was causing confusion.

In this commit, _only_ the `SNAPSHOT` release status is now compared differently (as if the 4th value is part of the version string).
@guusdk
Copy link
Member Author

guusdk commented Jan 3, 2025

This magic remains a bit of a hack, but it's arguably a more consistent hack with this change applied.

@akrherz
Copy link
Member

akrherz commented Jan 4, 2025

@guusdk I wouldn't mind seeing this go to 4.9 branch, can it? (well, might as well try the backport)

@akrherz akrherz added the backport 4.9 on merge, GHA will generate a PR with these changes against 4.9 branch label Jan 4, 2025
@akrherz akrherz merged commit b9f01e3 into igniterealtime:main Jan 4, 2025
18 checks passed
Copy link

github-actions bot commented Jan 4, 2025

Successfully created backport PR for 4.9:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 4.9 on merge, GHA will generate a PR with these changes against 4.9 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants