Re: Proposal of changing generating version of mdadm

["Tanska, Kinga" <kinga.tanska@linux.intel.com>]

> On 10/20/21 8:43 AM, Tanska, Kinga wrote:
>> Hi,
>>
>> recently we diagnosed few issues with 'mdadm -version' output.
>> Main problem is that end output varies on few conditions. We come with
>> simplified proposal. First let's describe current schema:
>>
>> mdadm - version - date - extraversion
>> (example: mdadm - v4.2-rc2 - 2021-08-02 - extraversion)
>>
>> or
>>
>> mdadm - version - date
>> (example: mdadm - v4.2-rc2 - 2021-08-02).
>>
>> VERSION could be taken from code (see ReadMe.c:31), but when git is
>> installed and .git directory is available in mdadm workspace, version
>> is replaced with output from # git describe HEAD command. It is assumed
>> that git command should return last tag from repo, which should contain
>> information about last release. This might not be true, especially if user
>> uses tags to mark internal milestones or custom mdadm spins.
>>
>> The second problem is DATE, which corresponds to date of last release.
>> When few patches are picked onto HEAD date is not reliable. In my opinion
>> DATE is not needed. Usually, packages do not contain this element, e.g.
>> -	# git --version
>> 		git version 2.27.0
>> -	# gcc --version
>> 		gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)
>> -	# yum --version
>> 		4.2.23
>>
>> To make it const and reliable, I propose removing DATE and always
>> use VERSION from code. VERSION shall keep general release information.
>> I would like to move the changeable elements into EXTRAVERSION. This
>> field will respect following conditions:
>> -	user definition first
>>         	(by respecting EXTRAVERSION=xxx during compilation)
>> -	if not defined by user, result of # git describe HEAD
>> -	else empty.
>>
>> Example output:
>> mdadm - version - extraversion (example: mdadm - v4.2-rc2 - extraversion).
>> Thanks for any opinion about this proposition.
> 
> Hi Kinga,
> 
> I am not against changing the format, however I worry that doing so may
> break scripts and tools in the field that nobody is maintaining or have
> thought of. If we are to change the output, I suggest making a new flag
> that provides the details you want and we can deprecate the old one, but
> leave it in place.
> 
> Thoughts?
> 
> Jes
> 

Thanks for your response.
I'm wondering if this change will be used if not will be set as default. 
I suggest providing a new flag with old, deprecated version, for any of 
uses where it couldn't be changed. I can add a description which clarify 
the change and describe flag, for anybody who will meet errors with 
scripts after this change.

Regards,
Kinga Tanska