On Mon, Jun 06, 2016 at 07:05:49PM +0200, Milan Crha wrote: > There is a bug to make more structures in Camel GObject based [2], to > be able to introspect it in a much easier way and so on. That change > will not be only a simple API change, it'll break core Camel things, > everything what uses it. If you open the [2], then I listed affected > projects at the end of the comment #5. It counts 18 projects. Maybe > there are more. I do not think I'd be able to coordinate the change in > a side branch for all of them, I (we) will surely provide patches in > the bugzilla around the time of the change landing, then it'll be up to > the respective maintainers to pick or reject them. What will the > Continuous do during this "broken period" is something I do not know. I > only know that the change will be for good. Introspection support for > the Mail part is good, I believe. Trying to revert such change in the > eds would hurt very much, no doubt.
There is a solution: bump the major version of Camel or EDS each time an API or ABI break is unavoidable, making the new major version parallel-installable with the previous ones. And that, every 6 months if needed (or one year if the development cycle is longer for the Evolution-related projects). Distros might not like that, but packagers should be encouraged to drop old major versions if it is no longer used by any package. (As a more practical matter, instead of hardcoding the API/major version a bit everywhere in the build system, see how it is done at: https://developer.gnome.org/programming-guidelines/stable/parallel-installability.html.en with @LIBRARY_API_VERSION@ in the Makefile.am etc. That way the API version can be bumped easily). One of the initial goals of developing a shared library is to reduce memory consumption. But with systems like Flatpak, that goal is fading away: there will be a new GNOME runtime version every 6 months. And with today's computers, is it more important to save, say, 100MB of memory, or to fluidize the development and ease big refactorings? -- Sébastien _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
