Ulf M�ller wrote:
>
> > Do we? We don't currently have a policy of incrementing version numbers
> > during development cycles.
>
> We don't have the policy to make incompatible changes to the API either,
> do we?
Yes, I'm afraid we do.
> Using the wrong pointer type is an *error* with g++, for example, so we
> need a way to detect this.
We can detect this _at the release level_ (or beta). People using
snapshots just have to keep up, I'm afraid. At least, that's the way its
been up to now. I'm reluctant to start versioning within development
cycles, because it is tedious.
What we should do, if we've agreed the version number format, is to set
the version to the current development version (0.9.3-dev/0x00903000) so
it can be distinguished from previous releases.
In case it isn't clear how this works, it goes like this:
Development 0.9.3-dev 0x00903000
Beta 1 0.9.3beta1 0x00903001
Beta 2 0.9.3beta2 0x00903002
.
.
Beta n 0.9.3betaN 0x009030nn
Release 0.9.3 0x00903100
Development 0.9.4-dev 0x00904000
The last two happen "at the same time" - that is, 0.9.3 only exists for
long enough to make a tarball. If we have to patch 0.9.3, making 0.9.3a,
then it becomes:
Release a 0.9.3a 0x00903101
This means people tracking the development version can distinguish it
from the previous release, and their code will work with the final
release without change if they track all the way to the end. We don't
support distinguishing an arbitrary snapshot of a development version,
though; only the latest. So, if you have support for a feature in 0.9.4,
then you test like this:
#if OPENSSL_VERSION >= 0x00904000
...
#endif
and it works through the development and release cycle.
Cheers,
Ben.
--
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]
