Re: Update of libchamplain version in external dependencies

[Jiří Techet <techet gmail com>]

On Sat, Aug 21, 2010 at 12:48, Emmanuele Bassi <ebassi gmail com> wrote:
> On Fri, 2010-08-20 at 22:03 +0200, Jiří Techet wrote:
>> On Fri, Aug 20, 2010 at 06:46, Andy Wingo <wingo pobox com> wrote:
>> > On Thu 19 Aug 2010 13:09, Jiří Techet <techet gmail com> writes:
>> >
>> >> right now libchamplain has the version number as a part of its name,
>> >> e.g. libchamplain-0.7.so.
>> >
>> > If you encode a version into the name, use the stable version. If 0.7 is
>> > a stable series, use -0.7 in the name. Otherwise if it is a development
>> > series, use 0.8 or whatever the next stable series will be -- as GTK+
>> > does.
>>
>> So does it mean I should use 0.8 in the name even for the development
>> 0.7 releases? I can do that even though it's a bit unusual (but
>> probably practical). I just took over the numbering scheme the
>> previous maintainer used which I think was inspired by clutter's 0.x
>> releases (the libraries were of the form libclutter-glx-0.x.so, where
>> odd x was a development version and even x was a stable version).
>
> the library name for Clutter always used API version in the soname and
> in the pkg-config file, to allow parallel installability.
>
> the problem is that we defined the API version as "$major.$minor",
> allowing parallel installability between development cycles and stable
> cycles. it was actually a mistake we continued for a while, and I
> strongly discourage anyone maintaining a library to follow that
> particular scheme: development cycles should always have the pkg-config
> and the soname of the next stable cycle, to allow an easier upgrade path
> for application developers.

Hi Emmanuele,

thanks for sharing your experience. I'll do it the way you and Andy
propose - use the stable version in the soname even for development
library versions. I plan to release a new development version (0.7.1)
in a few days and I'll change the soname for this release to contain
0.8.

If there are no objections I would then bump the module version in
jhbuild again so other modules depending on libchamplain can be sure
the stable API version is encoded into the library name and can change
their builds accordingly.

Cheers,

Jiri

>
> ciao,
>  Emmanuele.
>
> --
> W: http://www.emmanuelebassi.name
> B: http://blogs.gnome.org/ebassi
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list