According to Kyle:
"""
This already exists, albeit indirectly. There exist two built-in
constants:
jal_version : the version, currently 2004 (major * 1000 + minor)
jal_build : the build date of the release whose format is YYYYMMDD
"""
Though I understand we don't have accezs to "n", "o", etc, build date
should be enough.
to be tested
cheers
seb
--
Sébastien Lelong
Le 3 mai 2011 à 10:44, Joep Suijs <[email protected]> a écrit :
Hi Guys,
We could also ask Kyle to add an internal compiler function used to
identify
current used version while compiling in order to react differently.
We've discussed this before, e.g. on april 17, 2009. There is a
constant that indicates the compiler version 2.4, but does not take
the sub-verions into account. So we have to consider how to start from
there. One could argue that if compiler versions are so different that
the library has to take them into account, it deserves at least a
minor version update (so we should ask Kyle to consider this). If it
also has to do with dealing with beta versions, add a constant with
the version/compile date could be considered - automatic (so not
forgotten) and able to deal with minor changes during the beta-period
that do not get a new ID.
Joep
--
You received this message because you are subscribed to the Google
Groups "jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en
.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
