ABI and SONAME need a bump about libfm-qt HOT 11 CLOSED

See #428:

NOTE: pcmanfm-qt should be recompiled, preferably...

Please also check my pcmanfm-qt's PRs and if good, merge them (I use them for a while).

from libfm-qt.

libfm-qt's patches often require recompilation of all libfm-qt based apps.

from libfm-qt.

here the case is different - let's have a look at the diff

- (c++)"Fm::ThumbnailJob::readJpegExif(_GInputStream*, QImage&, int&)@Base" 0.12.0
+ (c++)"Fm::ThumbnailJob::readJpegExif(_GInputStream*, QImage&, QMatrix&)@Base" 0.14.2~

for additional symbols i can just increment the minor number, but this redefined symbol break backward compatibility - so a bump to a new major is needed - only one time as we don't care if we break compat within development cycle.

from libfm-qt.

For this specific case, I think the whole ThumbnailJob class should be hidden. Of course this is also an ABI-breaking change.

from libfm-qt.

Fm::ThumbnailJob::readJpegExif() is a private method. In this sense, that doesn't break backward compatibility (it's sometimes called "source compatible"). In the case of other senses, you're the master.

That being said, sometimes it's necessary to break backward compatibility in the code (not for users), in which case, I explicitly tell about it in my PRs.

from libfm-qt.

In other words, the code should be enhanced without caring about developers (like Gnome devs do) but with the utmost care for users (unlike what Gnome devs do). That's what I've always done — not my first time.

Versioning is outside my realm though.

from libfm-qt.

the bump will be needed somewhen just to prevent situations in which someone try a new libfm-qt with and old pcmanfm-qt - the cleanest way is to bump the soname version before a release (aka now) - if one compile things hisself nothing bad happends, but the very most distribution maintainers will see big fat warnings about this change and can react to it.

EDIT: So - the mentioned change is nothing bad, we should just not care about 😄 - but we shouldn't forget to bump before a release.

from libfm-qt.

Hmm - if the method is private and is not used outside of libfm-qt it shouldn't be exported first hand if possible.

from libfm-qt.

but we shouldn't forget to bump before a release.

I've changed ABI and API a lot but have never interfered with LXQt versioning process.

If I become responsible for versioning libfm-qt/pcmanfm-qt, I'll do it as in my projects (simultaneously releasing them every 2 months or so and bumping their versions after each release — and sometimes bumping it again, depending on the work I've done or my mood). So, never trust me when it comes to versioning ;) You're the boss there.

from libfm-qt.

Unrelated to our issue, but sometimes i think the same (bits from #d-qt-kde):

2019-06-02  20:46:38 <lisandro> that's exactly why I always say one should do a   
                     "maintainer boot camp" for developers
2019-06-02  20:47:25 <svuorela> heh

from libfm-qt.

:)

from libfm-qt.