[GNC-dev] Dependencies policy for major releases

[Geert Janssens]

Op zaterdag 29 oktober 2022 18:53:57 CET schreef john:
> What really makes sense? How many users are building for themselves and on
> what?

Here are a few of my thoughts on this topic (I threw away several earlier attempts because 
they became way too long...)

With my developer hat on I prefer to have as little conditional code as possible in the sources 
as this complicates reasoning about the code and makes it harder to test. So ideally no parts 
of the code that require certain versions of a dependency and other parts of the code for 
other versions of that same dependency. So that's the "most extreme" policy in John's 
writing. I am aware this is not always possible, especially as we offer gnucash on multiple 
platforms.

The other approach, where we freeze minimum dependencies on the stable branch, sounds 
like a nice compromise, but has the drawback that it makes the stable code more 
complicated in order to accommodate support for multiple versions of a dependency. So we 
trade the stability of an older dependency for complexity in our own code. I don't know if 
that's really a good trade-off for a small development team.

>From the perspective of an end user (on linux), the group affected the most are self-builders. 
A few have spoken up, but I have no idea of the size of this group in the wider community 
and whether or not they tend to run up-to-date distros.

The feedback we have received so far expresses a prudent willingness to self-build 
dependencies if needed.

On the whole my opinion is we can aim for more recent dependencies when it's useful, 
needed or desired.

How recent then can "more recent" be ? In my mind anything that's in the most recent LTS, 
should be fine in all cases. For anything more recent than that, we should consider how hard 
it would be to self-build the dependency.

Regards,

Geert