In message <cahej-s5q+2ccg7egfrvvh2gw4-ri4t5fvosxqnjbbj2jrao...@mail.gmail.com> on Mon, 26 Mar 2018 08:36:17 +1000, Tim Hudson <t...@cryptsoft.com> said:
tjh> https://github.com/openssl/openssl/pull/2181 tjh> and tjh> https://github.com/openssl/openssl/pull/1603#issuecomment-248649700 tjh> tjh> One thing that should be noted is that if you are building with tjh> -Wall -Werror (which many projects do) and you are using OpenSSL tjh> and things change from a const perspective builds break - and tjh> that then ends up people having to change code on released tjh> versions. tjh> tjh> Adding or removing const changes the API. I would like to point out that we're looking at two different const changes, and the distinction *is* important. One constification is changing the constness of a function's input parameter. Another constification is changing a function's return type. The impact of these two types of constification is very different (I would say "obviously", but I might be wrong, it might not be obvious to everyone), and they should be regarded different, not piled together in one "we do / do not allow constification in released branches". I'm going to argue that even though there are cases where one type of constification affects the other (such as constifying an input parameter might force a constification of the return type), they can still be looked at individually, and policy can be made on them individually. tjh> We should have a clear policy on doing this sort of thing in tjh> released code - either it is okay to do and we should accept tjh> patches - or it should never actually be done. I don't see this tjh> as a case-by-case basis for determination at all - basically it tjh> is a single type of API change we either should be allowing or tjh> disallowing. (a reminder: we're talking about *two* types of API changes that both involve 'const', not a single API change). I agree. We currently have a kinda sorta policy that's quite vaguely formulated in the FAQ (https://www.openssl.org/docs/faq.html#MISC7), and we do have something formulated in the release strategy (https://www.openssl.org/policies/releasestrat.html) as well. I'll note that none of them says "the API must not change". As a matter of fact, the release strategy only mentions binary compatibility (i.e. talks exclusively about ABI compatibility). The FAQ does mention source (i.e. API) compatibility, formulated as an implication: Changes to the middle number are considered major releases and neither source nor binary compatibility is guaranteed. This implies that we do guarantee source and binary compatibility. What that means exactly is left for us to discuss and decide upon. I would like to suggest that there should be a document where we collect what we think "compatibility" means, i.e. what we allow and disallow ourselves to do. Kind of a declaration of intention, if you will. This should be a document that can be edited over time (but with great care), and such changes should be voted on, of course. tjh> There is a similar type of API change which is adding typedefs in tjh> for callbacks - which technically also don't change the ABI - and tjh> if we allow any form of API change that also could be tjh> considered. tjh> tjh> We should discuss this separate from any specific PR and vote to tjh> set a policy one way or the other in my view. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project