[Pkg-gtkpod-devel] libplist/libimobiledevice releases

[Nikias Bassen]

Hi,

makes sense. Just FYI the next release of libimobiledevice, without a major version bump, will still follow the current versioning/naming scheme.
Hopefully in the next couple of days.

Regards
Nikias

> Am 02.07.2025 um 16:24 schrieb Yves-Alexis Perez <corsac at debian.org>:
> 
> On Wed, Jul 02, 2025 at 10:04:05AM +0200, Nikias Bassen wrote:
>> Hi,
>> 
>> thanks for your feedback. So that’s my point. I am talking about a situation where we would see a rename of all the libs of this project
>> (libplist, libimobiledevice-glue, libusbmuxd, libimobiledevice, libirecovery, libideviceactivation) because of the planned changes.
>> All libs and the related tools (e.g. idevicerestore, ideviceinstaller) would then be released at the same time with the name change.
>> And because we do have a name change anyway (e.g. libplist-2.0.* -> libplist-3.0.* libimobiledevice-1.0.* -> libimobiledevice-2.0.*)
>> I was thinking of removing the API suffix. This way, whenever we will see another major version bump, we would not
>> have to go from e.g. libplist-3.0.*.so to libplist-4.0.*.so but rather only bump the soversions properly.
>> Does that make sense?
> 
> If we're sure we won't have to change the library name of the soname
> again in the future, then I'm ok with that.
> 
> And I think we need to keep Debian and Ubuntu in sync as much as
> possible :)
> 
> Regards,
> -- 
> Yves-Alexis