Szakáts Viktor wrote:
+ Added HB_VERSION() unified version information function.
This can return these version related data:
hb_version( HB_V_HARBOUR ) => <string>
hb_version( HB_V_COMPILER ) => <string> hb_version(
HB_V_MAJOR ) => <num> hb_version( HB_V_MINOR
) => <num> hb_version( HB_V_REV ) =>
<num> hb_version( HB_V_STATUS ) => <string>
hb_version( HB_V_COUNT ) => <num> hb_version(
HB_V_DATE_TIME ) => <string> hb_version( HB_V_DATE
) => <date> hb_version( HB_V_TIME ) =>
<string>
Hi,
I would change _REV, _DATE, _TIME to less cryptic _REVISION,
_BUILD_DATE, _BUILD_TIME. And _V_ to _VER_ for the same reason. It's
just an idea, could be ignored.
HB_VER_* was already used on the C level for slightly
different meaning. But that was my first choice before
I realized. I don't like HB_V_ either.
HB_VERSION_* could also be good, but it's pretty long.
Or I can check what it'd take to rename C level HB_VER_*
to something else.
In this case I think HB_VERSION_ is better. A little longer, but this
constant will be used only in some seldom cases like .log creation etc.,
it's not STR() function.
BTW, what is HB_V_COUNT?
SVN revision. We can change it, but we need something
which doesn't contain the name of our versioning software.
Maybe HB_VERSION_SEQUENCE, HB_VERSION_REVISION would
be the best, but we have a slight term problem with
"revision" because we're using it for the last part
of the version number, and sometimes as the SVN revision
no, like in (Rev. 9732).
Is there a better term for the last part of our
version number? In 1.0._1_ the last '1' digit.
In cairo project version has major.minor.micro format. I like this name
'micro'. If we agree on it, HB_VERSION_REVISION will be a name having
the correct meaning.
Best regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
