Tracking Poppler master on binary factory

[Albert Astals Cid]

El dijous, 3 d’octubre de 2019, a les 10:55:52 CEST, Volker Krause va escriure:
> Hi,
> 
> I'm looking into the build issue of KDE Itinerary on Android on binary factory 
> (https://binary-factory.kde.org/view/Android/job/Itinerary_android/). 
> 
> The problem is the following: Itinerary uses unstable Poppler API, Poppler 
> changed that API in its master (but not its version number yet), Itinerary has 
> been adapted but that would only start to take effect once the Poppler version 
> number is bumped. So, with binary factory tracking Poppler master we now have 
> a combination that doesn't build.
> 
> I see three possible solutions:
> (1) Itinerary doesn't #ifdef by Poppler version but implements actual 
> configure checks that test for the API differences by trying to compile 
> corresponding code snippets.
> (2) Binary factory tracks the latest Poppler release instead of master.
> (3) Poppler bumps its version numbers right after instead of right before a 
> release.

The question is more, that is that CI job for? Is it something we want to give people so they use? Then it should not be using poppler master, i mean we poppler devs try not to break things, but it makes much sense to use a stable version if it's something you give to people to use.

If the CI job is there to catch this things, then 2 doesn't help.

My problem with 3 is that bumping the release early can result in people saying "but i have version X" when they really don't. But maybe that's going to be 0.1 people in the whole world :D

Cheers,
  Albert

> 
> How do we want to proceed? I can do (1), but that is quite some short lived 
> work that will only ever be useful until the next Poppler release. I lack 
> insight on whether (2) and (3) would be possible and/or how much work that 
> would be.
> 
> Thanks,
> Volker