Richard Levitte - VMS Whacker wrote:
ben OK, I propose that we follow the Apache version numbering scheme, which,
ben I quote:
ben
ben /* Numeric release version identifier: MMNNFFRBB: major minor fix final
ben beta
I assume "final" means "release"...
Yes, 0 for beta, 1 for release.
ben There are some serious problems with md32_common.h that I've run
ben into. However, I'll wait 'til the next rsync (in a few minutes)
ben to see if it has been resolved already...
ben
ben OK, care to say what they are?
It's been resolved. It was that HASH_BLOCK_DATA_ORDER wasn't
At 11:35 18.05.99 +0100, you wrote:
Richard Levitte - VMS Whacker wrote:
ben OK, I propose that we follow the Apache version numbering scheme,
which,
ben I quote:
ben
ben /* Numeric release version identifier: MMNNFFRBB: major minor fix
final
ben beta
I assume "final" means "release"...
babinebell Yes, 0 for beta, 1 for release. 2-f could be used for something else,
babinebell but I can't think what :-)
babinebell
babinebell 2 for next beta,
babinebell 3 for a interim release,
babinebell 4 for the betas based on 3
babinebell ...
No, I assume the version will be upped instead.
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
