Tracking Poppler master on binary factory

[Volker Krause]

On Friday, 4 October 2019 23:17:15 CEST Albert Astals Cid 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.

I don't think that level of detail is needed, we don't need to support random 
intermediate versions. If you track master, you can be expected to update to 
latest master IMHO, anything else is indeed too much extra work.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-android/attachments/20191005/a17a1b50/attachment-0001.sig>