PMM consistent versioning
General
Escalation
General
Escalation
Description
How to test
None
How to document
None
is triggered by
relates to
Smart Checklist
Activity
Show:
Denys Kondratenko November 17, 2022 at 11:00 AM
yes, it is
duygu.aksoy November 16, 2022 at 11:53 AM
is it still valid? ?
Denys Kondratenko September 20, 2021 at 8:34 AM
in there is good comment from :
Is there any reason why the following can't be done?
Feature branch PR-1716-17adb9e
Release candidate 2.16.0-rc
Release 2.16.0
The PMMVersion has been set the same here on the presumption that they are set by the same variable when building, but we check only Version and so it wouldn't matter if PMMVersion reflects something else here
Details
Details
Assignee
Unassigned
UnassignedReporter
Denys KondratenkoPriority
MediumLabels
Needs QA
Yes
Needs Doc
Yes
Smart Checklist
Open Smart Checklist
Smart Checklist
Open Smart Checklist
Created September 20, 2021 at 8:08 AM
Updated March 6, 2024 at 2:09 AM
User story:
There are a lot of confusions about PMM and PMM tools versioning.
It is also impossible to distinguish RC, Early Preview versions from UI.
Also there is a drawback with how pmm-update works and shows the date of the release.
We need more consistent way to distinguish between versions (dev, RC, early preview release, Release). Same with tools.
Also there should be a possibility for smooth update from dev to RC to Release.
There are number of tickets attached to this Improvement that provides more context.
UI/UX:
TBD
Acceptance criteria:
Update online and offline (with network connection and from local repos/registry), from any repo/registry (experimental, testing, release).
Clear message about current version.
Out of scope:
Suggested implementation:
How to test:
Details: