Philip Oakley [off-list ref] writes:
This patch series seeks to add tests for the version string format
and document it.
The key questions to be answered are:
* should the test be inside t0000, or somewhere else?
* should the version string be limited to one line, <80 characters?
One line, perhaps, but I do not think any byte-limit is reasonable.
It is unreasonable to limit the form to X.Y.Z; after we hit Git 2.0,
it is likely that we would go to two-decimals.
If the "parsing" is done for white/blacklist purposes, is there a
need to straight-jacket the verison string format like this series?
From: "Junio C Hamano" <redacted>
Sent: Sunday, April 14, 2013 8:22 PM
Philip Oakley [off-list ref] writes:
quoted
This patch series seeks to add tests for the version string format
and document it.
The key questions to be answered are:
* should the test be inside t0000, or somewhere else?
* should the version string be limited to one line, <80 characters?
One line, perhaps, but I do not think any byte-limit is reasonable.
OK
It is unreasonable to limit the form to X.Y.Z; after we hit Git 2.0,
it is likely that we would go to two-decimals.
Ah. And then maintenance releases could be the .Z maybe. I suppose it
will depend on circumstances.
If the "parsing" is done for white/blacklist purposes, is there a
need to straight-jacket the verison string format like this series?
The purpose is to document what we felt we could guarantee, and that
which was open to variation, so that those, like the Git-Gui, can code
in a sensible check for the version. Two digits (X.Y) should pass the
existing Git Gui check.
I'll drop the length limit, and keep to an X.Y check
Is the end of t0000-basic.sh a sensible place for the check?
--
Philip