FYI
-------- Forwarded Message --------
Subject: Re: [openssl-project] Release strategy updates & other policies
Date: Tue, 25 Sep 2018 13:37:48 -0400
From: Michael Richardson <m...@sandelman.ca>
To: Matt Caswell <m...@openssl.org>
replying directly, because the list is closed, but this is not private.
Matt Caswell <m...@openssl.org> wrote:
>> I also do think we need to document a few things like what we mean by
>> bug fix compared to a feature update as there are items which we
could
>> argue could either be a PATCH or a MINOR update depending on how we
>> describe such things.
> Sometimes we need to add a function in order to fix a bug. How should
> this be handled? e.g. there are 60 functions defined in
> util/libcrypto.num in the current 1.1.0i release that weren't there in
> the original 1.1.0 release.
As the thread shows this was problematic.
My answer is that applications either want 1.1.0, and should have a #define
that asks for that version only, and the headers would omit the 60 new
functions so that the new APIs would not compile.
(That let's 1.1.0LETTER be alpha released in attempts to fix things
without commiting to a particular API change)
Applications that want these 60 new functions need to ask for 1.1.0i
by "name", and get the new values. Or need to declare "I'm a developer"
This probably means that 1.1.0i should have been 1.1.1 or 1.2.0,
as semantic versioning wants to ignore that letter when looking for ABI
changes.
(Still looking for a VAX/VMS machine to test my unit tests on...)
--
] Never tell me the odds! | ipv6 mesh
networks [
] Michael Richardson, Sandelman Software Works | network
architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on
rails [
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
