Re: Continuous Builds in GNOME

[Sébastien Wilmet <swilmet gnome org>]

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