Fair comment, I'll respond to this as best I can, but this is not any kind of official statement.
On Wednesday 01 April 2009 14:01:18 Kurt Roeckx wrote: > Hi, > > I was under the impression that for the 1.0 version you would > change the API so that the ABI doesn't break all the time, and > I see no changed related to that. No, and please don't expect it to happen for v1.0. I speak only for myself, the others can agree/disagree as they please, but I think ABI compatibility is a fairly unrealistic dream when you take into account the SSLeay and OpenSSL legacy interfaces, current release management mechanisms, and community expectations (specifically souce compatibility, and in the case of stable-releases, even binary/shared-lib compatibility). The problem is circular - to get to ABI compatibility (and other desirable but far-away goals) would first require a large number of significant breaks in API compatibility. Resistance to the latter has historically been more evident, and certainly more immediate, than support for the former. However, we have been mulling over a new way of managing versions that would allow openssl to deliberately engage in API breakages across major releases (in ways that can be tracked, and which allow dependent libs/apps to prepare, etc), and to hopefully combine this with a more orderly/predictable release time-frame. The idea then is that working towards goals like ABI-stability would be possible in iterations that explicitly "break" certain legacy interfaces and behaviours, but do so in a clearly-defined manner. There would also be appropriate assurances for continued support of prior versions + adequate lead times to prepare for interface changes prior to major releases. The whole point is that there are types of progress we can't make by purely incremental and backwards-compatible steps, so this would be an attempt to address that without raising the ire of disgruntled users. But as for 1.0, the real issue there is that it has been baking for far too long, it is now neary 4 years since the last stable branch was cut (0.9.8) and the accumulated changes in the development head are overdue for a stable release branch of their own. In fact, the changes are quite wide-ranging even if they're mostly "under the covers", so v1.0 it will be. I believe/hope we will follow that up with improved process for subsequent releases in order to make more meaningful progress on the sort of significant issues/goals you hint at. The 0.9s have been incubating for ages now with a fairly strong "maintenance" focus, so even if the 1.0 release is not unlike another 0.9 release, the hope is that it marks a change towards an iterative process more focussed on "progress". At least that's my take on things. :-) Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
