Re: It's Release Notes time!
Hi Paul, On Thu, Aug 26, 2010 at 5:51 AM, Paul Cutler pcut...@gnome.org wrote: Hi, We're still pretty light on content for the upcoming 2.32 release. I just added some bullets off the top of my head about basic features Rygel's inclusion will add to GNOME. I'm not very good at this so please feel free to edit my text so to tailor it more for end-users. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update of libchamplain version in external dependencies
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
Re: It's Release Notes time!
Paul: This is the last (we promise!) release of the GNOME 2.x series - let's document the release as best we can. Add your news here: http://live.gnome.org/TwoPointThirtyone/ReleaseNotes Since many distributions ship GNOME 2.x in Long Term Supported releases, it might make sense to continue releasing updated modules with bugfixes and its possible that some GNOME 2.x modules may continue to be maintained (such as those needed to support non-OpenGL users). Therefore, it might not make sense to say that there will be no more GNOME 2.x releases. If, at some point in the future, there are enough important accumulated bugfixes in GNOME 2.x, it might make sense to do more GNOME 2.x releases. Just to help ensure that distros have available the highest quality GNOME 2.x code with the latest security patches, etc. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: It's Release Notes time!
On Thu, 2010-08-26 at 18:19 -0500, Brian Cameron wrote: Paul: This is the last (we promise!) release of the GNOME 2.x series - let's document the release as best we can. Add your news here: http://live.gnome.org/TwoPointThirtyone/ReleaseNotes Since many distributions ship GNOME 2.x in Long Term Supported releases, it might make sense to continue releasing updated modules with bugfixes and its possible that some GNOME 2.x modules may continue to be maintained (such as those needed to support non-OpenGL users). Therefore, it might not make sense to say that there will be no more GNOME 2.x releases. If, at some point in the future, there are enough important accumulated bugfixes in GNOME 2.x, it might make sense to do more GNOME 2.x releases. Just to help ensure that distros have available the highest quality GNOME 2.x code with the latest security patches, etc. Last 2.x release, but not last 2.32.y release? I'd assume accumulated bugfixes would just warrant another few micro releases, as they always have done. Philip Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: It's Release Notes time!
Last 2.x release, but not last 2.32.y release? I'd assume accumulated bugfixes would just warrant another few micro releases, as they always have done. However we want to handle it, I think we should be clear in the release notes that we have a plan in place for managing releasing ongoing support for GNOME 2.x, at least for a reasonable period of time. People reading our release notes should be assured that if their distro ends up providing only GNOME 2.x for a while, that we will continue to support them. We want to avoid distros patching GNOME 2.32 and not providing those patch fixes upstream, for example. If we give the impression that there will be no more releases, distros might not let us know about bugs or fixes they have. Also, it's hard to predict the future, so making proclamations about the last release only beg contradiction later on. Perhaps we could word it in a way that highlights that we do not have any future planned releases, but avoid proclaiming that we will never do something. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: It's Release Notes time!
On Thu, 2010-08-26 at 18:36 -0500, Brian Cameron wrote: However we want to handle it, I think we should be clear in the release notes that we have a plan in place for managing releasing ongoing support for GNOME 2.x, at least for a reasonable period of time. People reading our release notes should be assured that if their distro ends up providing only GNOME 2.x for a while, that we will continue to support them. Do we have a plan? Has the Release Team documented this anywhere? I can't write about it if I don't know about it. :) Paul ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
