OK, I propose that we follow the Apache version numbering scheme, which,
I quote:
/* Numeric release version identifier: MMNNFFRBB: major minor fix final
beta
* Always increases along the same track as the source branch.
* For example, Apache 1.4.2 would be '10402100', 2.5b7 would be
'20500007'.
*/
#define APACHE_RELEASE 10306100
Only using OPENSSL_VERSION_NUMBER instead, of course.
We can (ab)use the "beta" field to do version numbers like 0.9.3b
(0x00903102), though I'd hope that preceding a real release with
"official" betas will avoid the usual instant release of fixes.
So, I'd propose that we release, shortly, 0.9.3beta1 (note, yes, this is
a departure from Apache nomenclature - I'm trying to avoid confusion
with 0.9.3b) with the version set to 0x00903001. Leading through,
possibly, other beta versions, to 0.9.3, which will have version
0x00903100. When we release this beta version we will then freeze the
code until final release. I propose we do this on Wednesday (or Tuesday
if everyone is already ready).
Discussion of the "we could do it this way..." variety is not solicited.
Discussion of the "but this is wrong because..." variety is welcome.
BTW, yes, I _have_ noticed that when we get to major version 16 we can
no longer fit into 32 bits. I'm not seriously worried!
Cheers,
Ben [Release Manager].
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
