[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-09-04 Thread Christoph Feck
https://bugs.kde.org/show_bug.cgi?id=396713

Christoph Feck  changed:

   What|Removed |Added

   Version Fixed In|18.08.1 |18.12

--- Comment #12 from Christoph Feck  ---
This was committed to 'master' -> 18.12

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-08-19 Thread Nikita Sirgienko
https://bugs.kde.org/show_bug.cgi?id=396713

Nikita Sirgienko  changed:

   What|Removed |Added

   Version Fixed In||18.08.1
 Status|CONFIRMED   |RESOLVED
  Latest Commit||https://commits.kde.org/can
   ||tor/006013ba3416b2e0dd63926
   ||e270a932f7ce4f793
 Resolution|--- |FIXED

--- Comment #11 from Nikita Sirgienko  ---
Git commit 006013ba3416b2e0dd63926e270a932f7ce4f793 by Nikita Sirgienko.
Committed on 19/08/2018 at 18:27.
Pushed by sirgienko into branch 'master'.

Set SOVERSION cantorlib as 18.

Increase before release, if ABI changes (we can use abi-compliance-checker for
checking this)
FIXED-IN:18.08.1

M  +1-1src/lib/CMakeLists.txt

https://commits.kde.org/cantor/006013ba3416b2e0dd63926e270a932f7ce4f793

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Alexander Semke
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #10 from Alexander Semke  ---
(In reply to Antonio Rojas from comment #9)
> Frameworks is not really a good example since they have a stable ABI. See
> okular or ktp-common-internals for other KDE Applications projects that do
> this properly.
Ok. Thanks for the pointer.

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Antonio Rojas
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #9 from Antonio Rojas  ---
Frameworks is not really a good example since they have a stable ABI. See
okular or ktp-common-internals for other KDE Applications projects that do this
properly.

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Alexander Semke
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #8 from Alexander Semke  ---
(In reply to Antonio Rojas from comment #7)
> (In reply to Alexander Semke from comment #6)
> > (In reply to Antonio Rojas from comment #5)
> > > A major release in KDE Applications is every 4 months, not every year. So,
> > > unless you guarantee that you only plan to make ABI breaking changes in 
> > > the
> > > xx.04 cycles and not in the xx.08 or the xx.12 ones, this system doesn't
> > > make much sense
> > Yes, but the leading/major number stays constant for all releases within one
> > year - 18.04, 18.08 and 18.12. So, as long as you link against
> > libcantorlibs.so.18, or even libcantorlibs.so, everything should be fine,
> > shouldn't it?
> 
> No, it isn't. If you commit an ABI-breaking change in June to master, it
> will end up in the 18.08 release. This release will have a different ABI
> than 18.04 even though it has the same soversion, packagers won't notice
> that they need to rebuild stuff that links to it, leading to breakage. 
>  The only way the current schema makes sense is if you only allow breaking
> ABI between December and April, which seems to me a rather peculiar workflow

Ok. I got your point. Let us check how this is done in other KDE frameworks and
adjust accordingly.

As the author of LabPlot I'd rather like to combine both projects to get more
tigher integration and to also avoid this kind of problems with the stability
of the ABI...

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Antonio Rojas
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #7 from Antonio Rojas  ---
(In reply to Alexander Semke from comment #6)
> (In reply to Antonio Rojas from comment #5)
> > A major release in KDE Applications is every 4 months, not every year. So,
> > unless you guarantee that you only plan to make ABI breaking changes in the
> > xx.04 cycles and not in the xx.08 or the xx.12 ones, this system doesn't
> > make much sense
> Yes, but the leading/major number stays constant for all releases within one
> year - 18.04, 18.08 and 18.12. So, as long as you link against
> libcantorlibs.so.18, or even libcantorlibs.so, everything should be fine,
> shouldn't it?

No, it isn't. If you commit an ABI-breaking change in June to master, it will
end up in the 18.08 release. This release will have a different ABI than 18.04
even though it has the same soversion, packagers won't notice that they need to
rebuild stuff that links to it, leading to breakage. 
 The only way the current schema makes sense is if you only allow breaking ABI
between December and April, which seems to me a rather peculiar workflow

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Alexander Semke
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #6 from Alexander Semke  ---
(In reply to Antonio Rojas from comment #5)
> A major release in KDE Applications is every 4 months, not every year. So,
> unless you guarantee that you only plan to make ABI breaking changes in the
> xx.04 cycles and not in the xx.08 or the xx.12 ones, this system doesn't
> make much sense
Yes, but the leading/major number stays constant for all releases within one
year - 18.04, 18.08 and 18.12. So, as long as you link against
libcantorlibs.so.18, or even libcantorlibs.so, everything should be fine,
shouldn't it?

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Antonio Rojas
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #5 from Antonio Rojas  ---
(In reply to Alexander Semke from comment #4)
> (In reply to Antonio Rojas from comment #0)
> > Currently cantor uses KDE_APPLICATIONS_VERSION_MAJOR as SOVERSION for
> > libcantorlibs. This is totally wrong: the SOVERSION is meant to indicate the
> > ABI version and not to be arbitrarily increased once a year. This forces a
> > rebuild of applications that link to it (eg. labplot) once a year even if
> > there are no ABI changes. 
> > 
> > Please set SOVERSION to a fixed number that is only increased when there are
> > backwards incompatible ABI changes.
> 
> Here on openSuse labplot is linked against /usr/lib64/libcantorlibs.so.18
> which is a symlink to libcantorlibs.so.18.07.70. SOVERSION being set to
> KDE_APPLICATIONS_VERSION_MAJOR makes cmake to create that symlink. Whith
> this it is meant that Cantor guarantees the stability of ABI for one major
> release (for one year). This is basically the same what you suggest by
> setting this version manually to 18. Why do you get the problem with linking?

A major release in KDE Applications is every 4 months, not every year. So,
unless you guarantee that you only plan to make ABI breaking changes in the
xx.04 cycles and not in the xx.08 or the xx.12 ones, this system doesn't make
much sense

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Alexander Semke
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #4 from Alexander Semke  ---
(In reply to Antonio Rojas from comment #0)
> Currently cantor uses KDE_APPLICATIONS_VERSION_MAJOR as SOVERSION for
> libcantorlibs. This is totally wrong: the SOVERSION is meant to indicate the
> ABI version and not to be arbitrarily increased once a year. This forces a
> rebuild of applications that link to it (eg. labplot) once a year even if
> there are no ABI changes. 
> 
> Please set SOVERSION to a fixed number that is only increased when there are
> backwards incompatible ABI changes.

Here on openSuse labplot is linked against /usr/lib64/libcantorlibs.so.18 which
is a symlink to libcantorlibs.so.18.07.70. SOVERSION being set to
KDE_APPLICATIONS_VERSION_MAJOR makes cmake to create that symlink. Whith this
it is meant that Cantor guarantees the stability of ABI for one major release
(for one year). This is basically the same what you suggest by setting this
version manually to 18. Why do you get the problem with linking?

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Nikita Sirgienko
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #3 from Nikita Sirgienko  ---
I mean, there are tool for checking, that ABI was changed, because I don't
thinkg, that handling the version by hands will be very successfull (i think,
this is reason, why SOVERSION just setted by major version)

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Antonio Rojas
https://bugs.kde.org/show_bug.cgi?id=396713

--- Comment #2 from Antonio Rojas  ---
The number itself is not really important, as long as it is bumped when (and
only when) there is a new release which breaks existing API/ABI. Since it's
currently at 18, I'd suggest to set it to 18 for the current API

-- 
You are receiving this mail because:
You are watching all bug changes.

[cantor] [Bug 396713] Set a proper SOVERSION for libcantorlibs

2018-07-29 Thread Nikita Sirgienko
https://bugs.kde.org/show_bug.cgi?id=396713

Nikita Sirgienko  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED
 CC||warqu...@gmail.com

--- Comment #1 from Nikita Sirgienko  ---
I am not very familiar with ABI version management, what you could suggest?

-- 
You are receiving this mail because:
You are watching all bug changes.