Tracking Poppler master on binary factory

[Albert Astals Cid]

El divendres, 4 d’octubre de 2019, a les 23:22:36 CEST, Aleix Pol va escriure:
> Then you bump to .91?

I don't want to extra effort to do that.

Remember this is all KItinerary's fault because it's using unsupported API.

Cheers,
  Albert

> 
> On Fri, Oct 4, 2019 at 11:17 PM Albert Astals Cid <aacid at kde.org> wrote:
> >
> > El divendres, 4 d’octubre de 2019, a les 21:00:39 CEST, Aleix Pol va escriure:
> > > On Fri, Oct 4, 2019 at 11:59 AM Volker Krause <vkrause at kde.org> wrote:
> > > >
> > > > On Friday, 4 October 2019 00:35:11 CEST Albert Astals Cid wrote:
> > > > > 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.
> > > >
> > > > Right. Since this tracks master of the KDE repos too, I'd not assume this is
> > > > something for normal use, rather something for integration testing of all the
> > > > involved components.
> > > >
> > > > > 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
> > > >
> > > > Good point, that could be a problem. But wouldn't this happen the other way
> > > > around too, ie. people claiming they are on X - 1 while they are already
> > > > somewhere halfway on the way towards X?
> > > >
> > > > Regards,
> > > > Volker
> > > >
> > > > > > 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
> > > >
> > >
> > > That's why we usually do the .90 minor version trick, no?
> >
> > That doesn't really help either, you can't know if you're on the .90 version that has that new feature or not.
> >
> > Cheers,
> >   Albert
> >
> > >
> > > Aleix
> > >
> >
> >
> >
> >
>