<div dir="ltr"><div dir="ltr">On Sat, Jan 25, 2025 at 10:46 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org">kloecker@kde.org</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Freitag, 24. Januar 2025 18:57:43 Mitteleuropäische Normalzeit Ben Cooksley <br>
wrote:<br>
> I had been thinking that having a separate file that would be used instead<br>
> of .flatpak-manifest.yml if present when doing a build on a stable branch<br>
> would be a good solution.<br>
> Under this you would have a .flatpak-manifest.yml and a<br>
> .flatpak-manifest-stable.yml file<br>
> <br>
> When building on master the .flatpak-manifest.yml file would be used, but<br>
> when on a release branch / tag the .flatpak-manifest-stable.yml file would<br>
> be used instead (if present).<br>
> <br>
> That would eliminate needing the release manager / developer to update<br>
> .flatpak-manifest.yml on branching a new stable release branch.<br>
<br>
Doesn't that mean that the .flatpak-manifest-stable.yml file would be completely <br>
untested until the branching happens? We all know what happens if things are <br>
not tested on a regular basis.<br></blockquote><div><br></div><div>Yes, unfortunately this is one of those issues where we are going to lose either way.</div><div>You can either ensure your builds are reproducible and able to be replicated in the future by someone, or decide to chase upstream to ensure they haven't broken things and pulled the rug out from underneath you.</div><div><br></div><div>Both approaches have their pros and cons however we should understand that if we opt to chase upstream then our ability to produce CD builds that are suitable for end user distribution will be impaired.</div><div><br></div><div>In this instance we need to make a decision as to whether the Flatpak build is intended to be a CD build suitable for end-user distribution, or are we actually using it as another form of CI.</div><div>When it was introduced it was intended as a form of CD build.</div><div><br></div><div>I'll note that we should probably also tighten up how we handle our relationships with upstreams that break things too often and (strongly) encourage them to not break things.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Ingo<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>