search

ClusterLabs / crmsh

Command-line interface for High-Availability cluster management on GNU/Linux systems.
GNU General Public License v2.0
131 stars 94 forks source link

`crm --version` could be smarter than hardcoded #943

Closed zzhou1 closed 10 months ago

zzhou1 commented 2 years ago

tw1:~ # rpm -q crmsh crmsh-4.4.0+20220208.5e6dca1d-1.1.noarch tw1:~ # crm --version crm 4.3.0

liangxin1300 commented 2 years ago

fix in #946

nicholasyang2022 commented 10 months ago

We have version string in 3 places:

  1. configure.ac: populated into ./version and used by crm --version
  2. in setup.py: shown in pip freeze
  3. in crmsh.spec: shown in rpm -q

For 1. and 2., it is easy to be unified as shown in ef418e1c4016b5ffcaf0968b1164c569a5d137e7.

For 3., it is generated by obs source service. We are using tar_scm, which is able to get version information from git tags. However, this does not fit in our development procedures, as we need the version in rpm pumped for the 1st release candidate but the tag is created later when the code is stabilized.

A possible approach to make use of git tags and tar_scm is to create tag v4.6.0-rc1 for the 1st release candidate and let tar_scm extract 4.6.0 from it, so that it is no longer needed to hardcode the version in _service.

In conclusion, my proposal is:

  1. Create v4.x.x-rc1 tag, before submitting the 1st release candidate to obs. And let obs source service extract the version from the tag. This frees us from updating the version string in _service manually.
  2. Let setup.py read version string from ./version. This unifies the version string in crm --version and pip freeze.

With these 2 changes, there are still 2 sources of the version string. One is the git tags, another is the configure.ac.

nicholasyang2022 commented 10 months ago

Implemented in #1280, 1132830, and #1287.