On Mon, Aug 23, 2010 at 16:32, Jiří Techet <tec...@gmail.com> wrote: > On Sat, Aug 21, 2010 at 12:48, Emmanuele Bassi <eba...@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 <wi...@pobox.com> wrote: >>> > On Thu 19 Aug 2010 13:09, Jiří Techet <tec...@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.
I have just released libchamplain 0.7.1 with the above changes. I have also bumped the version in jhbuild and on the wiki and sent patches to * empathy: https://bugzilla.gnome.org/show_bug.cgi?id=628078 * eog: https://bugzilla.gnome.org/show_bug.cgi?id=628079 * emerillon: https://bugzilla.gnome.org/show_bug.cgi?id=628080 to update their dependency on libchamplain. Jiri > > 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 > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list