+ 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.
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.
So far to me it looks like the best would be to clean
the relatively internal HB_VER_* ones, and after that
I could normalize the HB_V_ ones.
Any further suggestion is welcome.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
