On 08/09/16 22:26, Anders Roxell wrote:
On 9 August 2016 at 08:54, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
On 08/09/16 02:36, Mike Holmes wrote:
On 8 August 2016 at 03:01, Maxim Uvarov <maxim.uva...@linaro.org
<mailto:maxim.uva...@linaro.org>> wrote:
On 08/05/16 21:27, Anders Roxell wrote:
On 2016-08-03 11:40, Maxim Uvarov wrote:
Signed-off-by: Maxim Uvarov <maxim.uva...@linaro.org
<mailto:maxim.uva...@linaro.org>>
---
configure.ac <http://configure.ac> | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac <http://configure.ac>
b/configure.ac <http://configure.ac>
index c0eb207..bd16370 100644
--- a/configure.ac <http://configure.ac>
+++ b/configure.ac <http://configure.ac>
@@ -12,10 +12,10 @@ AM_SILENT_RULES([yes])
##########################################################################
# Set correct platform library version
##########################################################################
-ODP_LIBSO_VERSION=110:0:1
+ODP_LIBSO_VERSION=111:0:0
AC_SUBST(ODP_LIBSO_VERSION)
-ODPHELPER_LIBSO_VERSION=110:0:1
+ODPHELPER_LIBSO_VERSION=111:0:0
AC_SUBST(ODPHELPER_LIBSO_VERSION)
The SO-version doesn't need to change. The SO-version only
needs to be
changed when an interface has been added, removed, or modified
since
the last update [1].
For this release the API version should be changed and we
should change
the version in include/odp/api/spec/version.h.
Cheers,
Anders
[1]
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
<https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html>
Yes, but it's looks like very strange for me if .so version
110:0:0 and odp version is 1.11.0.0.
I think that also can be confusing for other people and not clear
how to patch .so version
to tag in git repo.
It should not be confusing for people, linux is very specific about the
rules for a .so version.
We are trying to be very specific in our API release numbering doc.
On OS "wherever" you can be completely sure the API number will not match
that OS'es mechanisms for version libraries.
I'm not big expert in deploying .so to mainline. But I'm agree with Bill
that .so version should match to api and tar ball name.
No it should not.
Projects building on top of ODP shouldn't have to rebuild if we do a
new release that only adds new APIs.
ok, that is logical.
The only time they should have to rebuild is if we break ABI (delete
or rename an API).
ok, we change TM API:
https://git.linaro.org/lng/odp.git/commitdiff/a560c609e78716421e782aa388805937d177ef0e?hp=524987a32f9873e59ce265ffba6e831e756a2441
When a new version of a library is binary-incompatible with the old
one the SO-version needs to change.
yes, 1.10 is incompatible to 1.11, we need to change version.
Again, did you read the link I pasted in the other email [1] ?
Especially this snippet: "Never try to set the interface numbers so
that they correspond to the release number of your package. ..."
Cheers,
Anders
[1]
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Ok, than numbers has to correspond only to API. I.e. first 2 digits in
our API code.
From doc -release option is not clear where is has to be set.
"""
Instead, use the -release flag (see Release numbers
<https://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html#Release-numbers>),
but be warned that every release of your package will not be binary
compatible with any other release.
"""
is it set by autotools automatically somewhere or we should add it to
configure.ac also?
Maxim.
