Bug 1400054 - [RFE] Output of heketi-cli --version should also provide the Release number
Summary: [RFE] Output of heketi-cli --version should also provide the Release number
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: heketi
Version: cns-3.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Michael Adam
QA Contact: Prasanth
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-30 11:22 UTC by Prasanth
Modified: 2017-01-23 15:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-20 10:55:21 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Prasanth 2016-11-30 11:22:33 UTC
Description of problem:

Output of heketi-cli --version should also provide the Release number. Currently the output doesn't provide the Release (R) number and so it doesn't help the user much while trying to understand which version is having the issue by looking at the version, until the user actually checks for it's RPM version. 

The current output is given below:

# heketi-cli --version
heketi-cli 3.1.0

It would have been helpful if it was like:
# heketi-cli --version
heketi-cli 3.1.0.3

Version-Release number of selected component (if applicable):
heketi-client-3.1.0-3.el7rhgs.x86_64

Comment 2 Michael Adam 2016-11-30 11:44:31 UTC
This is an RFE.
Not for 3.4.

I am not convinced of this.

* The --version option is provided by upstream code
  and provides the upstream version of the code used.

* The rpm Release number is a distribution/packaging
  specific entity. Imho this should be reflected by
  the --version but users can look it up with rpm -q heketi.
  or so.

* even if we were to do it, it's complicated and fragile,
  since it involves carrying a patch in the spec file
  that needs to be adapted each time we do a new build.

Happy to hear other people's opinions, but I'm inclined
to reject this as wontfix altogether. Opinions?

Michael

Comment 3 Michael Adam 2017-01-20 10:55:21 UTC
no comments yet --> closing it


Note You need to log in before you can comment on or make changes to this bug.