[sword-devel] SWORD 1.7.0RC2

Jaak Ristioja jaak at ristioja.ee
Mon Aug 12 01:46:18 MST 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12.08.2013 10:34, Troy A. Griffitts wrote:
> OK, I've put together a scheme which moves the new version macros
> into our swversion.h file.  The new scheme goes out to 4 segments
> as we support in the SWVersion class.  Here are the defines.
> Please add your comments and ask question, but I hope these will be
> self-explanitory. My only concert about SWORD_VERSION_NUM is the
> possible size we might get to if we ever get to 5.0.  Don't know
> how compilers handle macro checking on values over 4GB.
> 
> #define SWORD_VERSION_NUM 106902000

In C++03 preprocessing (translation phase 4) happens before things are
converted into C++ tokens (phase 7). Hence this should cause no
trouble during preprocessing. After that, if the literal without a
suffix fits into an int, it is an int. If it fits into (long int) it
is a long int. Otherwise the behavior is undefined. In case its type
would be a 32-bit signed integer type, our maximum version would be
21.47.483.647.

Why don't we just have 106902? Do we really need the extra 000
(VERSION_NANO) at the end? If not, we could have version numbers up to
21474.83.647.

If we'd use hex, e.g 0x010700 it were easier to count the bytes, and
the Alpha, Beta and rC versions could be marked like 0x0106a0,
0x0106b2 and 0x0106c3.

> As for RCs, I've always bumped the subsequent segment up to near
> max (901 for RC1).  Not sure if this is standard but it keeps the
> versions sortable and is mostly obvious to a human what is going
> on.  I'm happy to change this is someone has problems with it.

I'm not sure its standard. I currently have no greater problems with
it than written above, but I must stress that it is most important
that the format of SWORD_VERSION_NUM would not change in the future in
a way which would break preprocessor version checks. Because a version
macro is what C++ developers usually use to work around or adapt to
API/ABI changes. If the version macro itself changes format, things
might get ugly.

The formats I've seen most are 0xMMNNPP (hexadecimal) and MMNNPP
(decimal) where MM, NN and PP are major, minor and patch versions
respectively.

My current personal preference is 0xMMNNPP with PP as a# for alphas,
b# for betas and c# for release candidates. This is relatively simple,
easy to understand and short. If we want, version 12.0.0 can still be
0x120000 (instead of 0x0c0000) by agreement, since this doesn't break
the version number comparisons. I doubt any of the minor version
components ever go past 0x99 (meaning decimal 99) for the 0xa# etc
meant for alphas, betas and rc's.

Thank you Troy for taking time for all this. :)

Blessings,
Jaak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQgcBAEBAgAGBQJSCKCYAAoJEEqsYmEt1rCOr+U//RVaMf2Sr4Jz50IaYOdAv6Cl
FQyQfu0kfEmJvFNyyhCbKJQhLU4/ddjVGxQYAE5D4nuZBTGSCas5fOCmmdMYtpF/
UtFOuo//ML01NZ+cKKvsvF6iSD2OQKbFb5xDJrIZ4wBnHQxeHQRecvg232RRrcTD
37F599zXl7D0T03QBdX0XTf3MkACMg8B5YzCB1fjPWcvdzjibI5Lfj8FsuumnJ1L
TiLJP6cR81VkColZru6cSotwy6xVC3usIOgcdsty8OL8dNFNDvACvR2KEXIK/bMs
i9ljJ0bDJNB/+ekHrPhl4qbmdcSwsbLgzJJZLxqmGi2vu8p2DfeV3kiF+XGT78Gg
6SqahB+YuYh4nPii/e8nhnUw3SzoDxrghbs/7HKcYGdk1IvcPZhG9SJjdFOOKJri
gK4T+U0Nwn6xmK0Zgljb+3C6U6adkDEwiH12YPh4uKqbH1AG6qYC8lYPqgxBZ8i7
EGWtoL1316Nyg+HTlRMiqAXUbs5eekRb826ZPwQiiqyq1gVtvzWWdVbyu9166/W8
JaHcwDjYYIL2dU5PcrPQdp4zpF7pfomEFr10NmxZl7HfWZ/k4x2UrUiJzludxY2K
xHnLh1XlcEIbLYW4eqhSXfIUW1t0jJKTuJQZfJZwN/mTUR2HQelY2WI3dYq3LvmP
j2tRh7zRsGvrIMUr8FKiyjD1BZHaT7Z8Ejnauu18YUMlubCyF1uUCbVWz+Zb2Bd+
rYstT9k0VAf+KlFj4l6gNdwvs7zJIa2sSDR46dPDH9Kf9iR1l0Jr8uT5KsoSVpa4
7dmFSlUUzYANa9ZLVzbGWPVZB/6xG68kKCrhFWGcJ/Sn7uAyvQVygBEaNriLTZ8S
G3Hw3OR0byUT476OF7AmYYmQ6331SOIOB1biZvzRlTb0nutBv7Ws3No0VlU5pE/T
nEkWPc9kIXV9huqq43TFU4rpEA/+bVPxbEYmzJWKqNRmuOMP3Y5K1qZuxKteL4yK
c4sI+QTwp8yMUxmag2sghVCscbCrcqDfFMMRPV7R6scSq5t0GIEK6SbRMC+E3Hqp
+j/8yDnKl9RVyB5OCe7eC2eKyUDEDEzZWJCBcXX/sqCnpGL7VG8MFDOvH9E4/2Ck
CzT4FdY6akiO9uiPR5YKJyQkVd0LL1WbG8otJT0knd/viyI8xe+YfZqEjGGKYj7e
U81PF3BzljQiY+EFpH+AukzaYoYd6qJN1DRxWYs2BHuJAOag5DlNpndPguteVyGb
Gm+IZYW1BZO8IVw6m3djF2GXasMSZByGNh4dqmT/MpgUBCW/+xHM4xVUES1p0lcu
Lrn50CPSxX/CG2xsxGHk54/7A3QFmx4gj5L7OwB/NIJWnhwm+EBXyhdLoRmFPy4k
YOuqnvx3tpxH5SehzbsYNMyXGjrRbanH3fKa7hfiKcp+Eqm0xbYWrtiyVMOKmlIB
EJQXJwLIRShbvldi29PUSuzpfS1RsffIAGMRwyutoOaoxXkG6BGgzHBW+wVdxr5M
J3jVnfK/7p+uQvgAt12TuTF4YOh+bWUMOZ+pRvIEEDGd5gOLOfA42lqfRMf/cDH8
b5W8zaws090i68KclpBamqy2gLuetfSAUX9m1ikt9dj941IyO/2r5KDjAYy+nFzI
3KrP1ruY0NLH9jZGYB3qGxEuw59f7UW9iZjH6j+xwVXQ16Xa2C84ir814QBETpen
4/FQ37MulLPhLKVJcAk0JWlH79TCFsN9uqJ+Vsbs1cIUj+Ktsdt/dWriIKjoaBZI
T0ZOiK43intU29qqpfMFoPxS2R/0L8uZb0295I8FbCfUEuLd18/yxC6BLq1lof+J
rFJ/mXreBtBk0qacGsgvBwaMCKuPtUU+jqVEGuFh0eviTirauUKqjXjmLGmXjqWD
orJN9DRh98Ml0/d+1PBYkPpsrmmH33UJfXk9y9sqaWMtC+M+tECZEXrZkk/xFjnR
AQvtYOSvnghbdNb/WBI68twutuTq5hhlNXcXKA5rNc97aZ2oMpY62L8PmFEZLpG7
zdFh48t0b858c8lEi0fQC5c4zaf08m+QWo1zx0tdCAFr892+99dwKYlESF0B9wSG
/XOKz/kEcKCSRoi+MQv8he2j/RDejYYd7gFIPAIgVIeEN3CZKgJqkApx8arq9X2w
6lOUF20lfl97y/E9kAFz893YbTCLLBUszzJr6ZQ+54GFHZ6511EOSYsw2k8C9b7B
jXq+xWPxy5GLNd7FitzVWbSCOrocOIPU4LF6lvNYCSMX+3ODSpq993Tatn5f+3wO
yFXiCWvXoJWHFdgZe2f3ypVFQfwsuzBXRS6svUo0pTR4FlAeI87JE3vQR4vBRope
hTEYXO3tXrbFiRJyo8mOXqwvY+LNaL90a3C7lD9cF463EoZkxa9TrcocxuwT+S7n
tkUru5SqreN+dOeljOFtyjPbOl74SiGdpbS0SUw/OXw43YQklAd96BeKZiL3amtz
3InJ9dU5LZY/f8LDlteIt7GMkyaKcfM7a8XQkS34fReq3z/88i1KWrAf3ZkqtjL/
BoCWnc1wAfSLcyvir3oJu9NeY3th7P0nC7lhVGULVJ6QvaNGH9Ui4I29kmrQ5+Zw
kamwQSRVa4rhOGi/FYS+GD7epYF1AlopnEeWKx9H2AJ58holwj2aY+PC00n64HQR
Xm1W0o1JHuKfLmre/b+cOw/3EyRubIQmx+qENx7Ca4WYWbrMN2uPBaZSka8DmB0J
mKGQQKF87fR143RDKGvF
=1y+s
-----END PGP SIGNATURE-----



More information about the sword-devel mailing list