* Proposal of changing generating version of mdadm
@ 2021-10-20 12:43 Tanska, Kinga
2021-11-02 15:53 ` Jes Sorensen
0 siblings, 1 reply; 4+ messages in thread
From: Tanska, Kinga @ 2021-10-20 12:43 UTC (permalink / raw)
To: linux-raid; +Cc: jes
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.
Regards,
Kinga Tanska
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Proposal of changing generating version of mdadm 2021-10-20 12:43 Proposal of changing generating version of mdadm Tanska, Kinga @ 2021-11-02 15:53 ` Jes Sorensen [not found] ` <MN2PR11MB3776D436514419C88FD67B61899F9@MN2PR11MB3776.namprd11.prod.outlook.com> 0 siblings, 1 reply; 4+ messages in thread From: Jes Sorensen @ 2021-11-02 15:53 UTC (permalink / raw) To: Tanska, Kinga, linux-raid 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <MN2PR11MB3776D436514419C88FD67B61899F9@MN2PR11MB3776.namprd11.prod.outlook.com>]
* Re: Proposal of changing generating version of mdadm [not found] ` <MN2PR11MB3776D436514419C88FD67B61899F9@MN2PR11MB3776.namprd11.prod.outlook.com> @ 2021-11-22 13:04 ` Tanska, Kinga 2022-01-19 13:57 ` Tanska, Kinga 1 sibling, 0 replies; 4+ messages in thread From: Tanska, Kinga @ 2021-11-22 13:04 UTC (permalink / raw) To: jes; +Cc: linux-raid > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Proposal of changing generating version of mdadm [not found] ` <MN2PR11MB3776D436514419C88FD67B61899F9@MN2PR11MB3776.namprd11.prod.outlook.com> 2021-11-22 13:04 ` Tanska, Kinga @ 2022-01-19 13:57 ` Tanska, Kinga 1 sibling, 0 replies; 4+ messages in thread From: Tanska, Kinga @ 2022-01-19 13:57 UTC (permalink / raw) To: jes; +Cc: linux-raid > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-01-19 13:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-20 12:43 Proposal of changing generating version of mdadm Tanska, Kinga
2021-11-02 15:53 ` Jes Sorensen
[not found] ` <MN2PR11MB3776D436514419C88FD67B61899F9@MN2PR11MB3776.namprd11.prod.outlook.com>
2021-11-22 13:04 ` Tanska, Kinga
2022-01-19 13:57 ` Tanska, Kinga
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.