Re: [ITP] cairomm, as replacement for cairomm1.0

[Ken Brown <kbrown@cornell.edu>]

On 5/25/2020 11:31 PM, Yaakov Selkowitz wrote:
> On Fri, 2020-05-15 at 11:30 -0400, Ken Brown via Cygwin-apps wrote:
>> cygport file attached.  I've bumped the version to 1.12.2, which is the latest
>> stable upstream release.  Upstream has actually released 1.15.5, but the News
>> file says it's unstable and recommends that distros not package it.
> 
> GNOME still uses the development/stable odd/even-minor versioning
> scheme (like the Linux kernel used to long ago).
> 
>> I'm proposing an unversioned source package cairomm, as well as unversioned
>> devel and doc packages.  This is what we do with many library packages, and it
>> is consistent with Fedora's packaging.
> 
> I would strongly recommend against this rename, and in fact it is
> Fedora that might have to adapt, because:
> 
>> It will also ease future maintenance.  I've looked at the upstream git repo, and
>> there's been an ABI change from 1.0 to 1.14 and then to 1.16.  It would be
>> annoying to have to create a new Cygwin package for each such change.
> 
> 1.0 isn't an ABI version, it's an API version, and like many GNOME
> libraries, the GTKmm bindings carry the API version in all its
> directories and library names, so that multiple versions may be
> installed in parallel.  (Any given application can use only one stack,
> but you can have some apps using the new and other apps using the
> current until they update.)  Cairo is relatively newer than the rest of
> the stack, and so it hasn't been through this process before, but the
> others have.
> 
> (That's they the current versions are e.g. 2.4 instead of 2.0, because
> the upcoming versions will be the third or even fourth API version for
> most of these packages; the previous versions were obsolete a LONG time
> ago.  In fact, just remembering going through this last time, and then
> realizing how long ago that was, isn't making me feel any younger. :-)
> 
> With the introduction of libsigc-3.0, this and the rest of the GTKmm
> stack is going to undergo a(nother) API version bump, with the new
> versions should be parallel installable with the current:
> 
> Current: libsigc-2.0, glibmm-2.4, cairomm-1.0, atkmm-1.6, pangomm-1.4,
> gtkmm-2.4 and -3.0,
> 
> New: libsigc-3.0, glibmm-2.66, cairomm-1.16, atkmm-2.30, pangomm-2.44,
> gtkmm-4.0, etc.
> 
> We're going to want to be able to have both for a period of time, and
> of course this could always happen again in the future.  That's why
> they always been, and should remain, versioned.

I'm convinced.  Thanks for the detailed explanation.

Ken