On Sun, Nov 08, 2009, David Woodhouse wrote: > I'm still trying to understand what this actually means in practice, and > who the target audience is for the various branches. > > Presumably, most of the conservative OS distributions (Solaris, > "Enterprise" Linux distros, various BSDs) will stick with 0.9.8 for the > time being. > > Those who are more versatile will be updating to 1.0.x -- some of them > like Fedora are there already, in fact. > > So is there really any point in a 0.9.10 release? Who would actually > want to use that, and what would be in it? > > In the meantime, there are people who are trying to get features into > the codebase that people actually use -- Intel's AES-NI support, IBM's > AES-GCM/AES-CCM/CMAC, etc. > > The normal response from distributions is, quite reasonably, "get it > into 0.9.8 upstream and then we'll talk". Which is obviously not such a > realistic proposition any more -- so what happens next? >
The aim of the 0.9.10 release (and the 1.0.1 release) is to allow new features to be added more quickly than a major release and to reduce the possibility of introducing problems in a stable release. When we want to add a new feature to OpenSSL in the old scheme it could go into HEAD and it would become part of the next major release. However major releases only occur every few years and there was a need to be able to add features more quickly which didn't break binary compatibility. So the idea was to separate the bugfix and "timely new feature" versions. So someone who wishes maximum compatibility and least risk of any problems would stick with the letter changes. Those who want newer features with small risk issues would go with final number changes that is 1.0.1, 1.0.2. If there was a need to add such features to the 0.9.8-stable branch (for example that's the only version which can be currently used with the FIPS140-2 validated module) it would go into 0.9.10 that may not happen and there may not be a 0.9.10 at all. Finally bleeding edge major changes for developers or users who can live with possibly unstable and occasionally uncompilable code can stick with the unstable branch which will be 1.1.0 and later. The various AES features you mentioned would be candidates for 1.0.1. It was hoped that the final or penultimate beta of 1.0.0 would be out by now but the renegotiation issues have thrown everyones schedules off. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
