Re: KDE Gear projects with failing CI (master) (21 January 2025)
On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit Albert Astals Cid wrote: > neochat - NEW > * https://invent.kde.org/network/neochat/-/pipelines/869365 > * flatpak build fails Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I guess, looks like an API change in libQuotient with the corresponding version change still pending (ie. a similar problem we occasionally hit with Poppler). The quick solution for this would probably be (temporarily) switching Flatpak to the latest release of libQuotient. The IMHO proper solution would be to have version bumps at the beginning of a development cycle that changes API. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (21 January 2025)
On Thu, Jan 23, 2025 at 5:49 AM Volker Krause wrote: > On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit Albert > Astals Cid wrote: > > neochat - NEW > > * https://invent.kde.org/network/neochat/-/pipelines/869365 > > * flatpak build fails > > Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I > guess, > looks like an API change in libQuotient with the corresponding version > change > still pending (ie. a similar problem we occasionally hit with Poppler). > > The quick solution for this would probably be (temporarily) switching > Flatpak > to the latest release of libQuotient. The IMHO proper solution would be to > have version bumps at the beginning of a development cycle that changes > API. > This also raises another question though - should we be strongly discouraging use of heavily moving targets like upstream dev / master branches and instead favouring the use of stable branches? Not really ideal if upstream can essentially break our builds without us doing anything. > > Regards, > Volker Cheers, Ben
Re: KDE Gear projects with failing CI (master) (21 January 2025)
On 23/1/25 07:26, Albert Astals Cid wrote: El dimecres, 22 de gener del 2025, a les 19:19:23 (Hora estàndard del Centre d’Europa), Volker Krause va escriure: On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben Cooksley wrote: On Thu, Jan 23, 2025 at 5:49 AM Volker Krause wrote: On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit Albert Astals Cid wrote: neochat - NEW * https://invent.kde.org/network/neochat/-/pipelines/869365 * flatpak build fails Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I guess, looks like an API change in libQuotient with the corresponding version change still pending (ie. a similar problem we occasionally hit with Poppler). The quick solution for this would probably be (temporarily) switching Flatpak to the latest release of libQuotient. The IMHO proper solution would be to have version bumps at the beginning of a development cycle that changes API. This also raises another question though - should we be strongly discouraging use of heavily moving targets like upstream dev / master branches and instead favouring the use of stable branches? Not really ideal if upstream can essentially break our builds without us doing anything. I can't comment on NeoChat, but for Itinerary the builds against the latest versions of essential (external) dependencies with varying intentions/success in keeping backward compatibility (ZXing, Poppler, Quotient) are very much deliberate, to catch breakage/regressions early (same as we are now doing for KF with Qt pre-releases). And this is actually working, NeoChat has been fixed to build with the upcoming Quotient version, same for Itinerary/Poppler. I'm fine with break-things-early if we have a fix-things-early outcome from it :) Cheers, Albert And this is generally the case with NeoChat as several of the main contributors also work on libquotient upstream. The only thing we are missing for those fixes to take effect is those dependencies bumping their version numbers. We could work around that by doing configure-time detection using a compile test, but that's a lot of extra work, so we'd better try to address this upstream first. I'd very much suggest the use of release tarballs (or stable branches) for apps that aren't continuously monitoring their dependencies this way though, but I'm not aware we have such a case. Regards, Volker
Re: End of life policy
On 23/1/25 03:06, Albert Astals Cid wrote: El dimecres, 22 de gener del 2025, a les 4:35:53 (Hora estàndard del Centre d’Europa), rhkra...@gmail.com va escriure: On Tuesday, January 21, 2025 05:16:25 PM Albert Astals Cid wrote: Is it not a consequence from the fact that there's no more releases planned? It's weird to say "for things that we don't plan releases there will no be releases" What would you write? From the peanut gallery: How about: No more releases planned for this project. and perhaps, in parenthesis after that, something like (end of project) But we're not speaking about end of project. We are speaking about the fact that Okular 24.12.x is not going to be released anymore because Okular 25.04.x is the next release series, not that we're not going to release Okular at all anymore. Cheers, Albert Further to this one, perhaps on the announcement posts when new Plasma, Gear or Frameworks is announced we could let people know e.g. Plasma 6.2 is out! Please note: Plasma 6.1 and below will no longer receive any bug fix or security updates.
Re: End of life policy
On 23/1/25 03:06, Albert Astals Cid wrote: El dimecres, 22 de gener del 2025, a les 4:35:53 (Hora estàndard del Centre d’Europa),rhkra...@gmail.com va escriure: On Tuesday, January 21, 2025 05:16:25 PM Albert Astals Cid wrote: Is it not a consequence from the fact that there's no more releases planned? It's weird to say "for things that we don't plan releases there will no be releases" What would you write? From the peanut gallery: How about: No more releases planned for this project. and perhaps, in parenthesis after that, something like (end of project) But we're not speaking about end of project. We are speaking about the fact that Okular 24.12.x is not going to be released anymore because Okular 25.04.x is the next release series, not that we're not going to release Okular at all anymore. Cheers, Albert I guess I should try to expand on my thoughts before throwing my ideas at the mailing list. I think my original thought was several fold: 1. How long/which version (tied together as our releases are done at regular intervals) do we support each release for things KDE produces, e.g. Gear, Plasma, Frameworks? 2. Document this information clearly on our Wiki. 3. On the documentation side, have a single Wiki page per release type (Gear, Frameworks, Plasma) that details this. for example: Gear Current supported versions: 24.12.* Version Release Date Supported == 24.12 Released 19th December 2024 Yes 24.08 Released 5th August 2024 End of Life* ... All the older releases... * End of Life text would be a link to a page on the wiki would describe that KDE software is regularly released and it is always recommended to upgrade to the latest released version. End of Life software does not receive important security updates or bug fixes. More text here about why that is important, etc. I think my goal overall is to set expectations for users and developers clearly on our wiki. Don't target End of Life software for development and let users know that versions like 24.08, 24.05, 24.02 etc on LTS type distros are not supported any longer.
Re: KDE Gear projects with failing CI (master) (21 January 2025)
El dimecres, 22 de gener del 2025, a les 19:19:23 (Hora estàndard del Centre d’Europa), Volker Krause va escriure: > On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben > > Cooksley wrote: > > On Thu, Jan 23, 2025 at 5:49 AM Volker Krause wrote: > > > On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit > > > Albert > > > > > > Astals Cid wrote: > > > > neochat - NEW > > > > > > > > * https://invent.kde.org/network/neochat/-/pipelines/869365 > > > > > > > > * flatpak build fails > > > > > > Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I > > > guess, > > > looks like an API change in libQuotient with the corresponding version > > > change > > > still pending (ie. a similar problem we occasionally hit with Poppler). > > > > > > The quick solution for this would probably be (temporarily) switching > > > Flatpak > > > to the latest release of libQuotient. The IMHO proper solution would be > > > to > > > have version bumps at the beginning of a development cycle that changes > > > API. > > > > This also raises another question though - should we be strongly > > discouraging use of heavily moving targets like upstream dev / master > > branches and instead favouring the use of stable branches? > > Not really ideal if upstream can essentially break our builds without us > > doing anything. > > I can't comment on NeoChat, but for Itinerary the builds against the latest > versions of essential (external) dependencies with varying > intentions/success in keeping backward compatibility (ZXing, Poppler, > Quotient) are very much deliberate, to catch breakage/regressions early > (same as we are now doing for KF with Qt pre-releases). > > And this is actually working, NeoChat has been fixed to build with the > upcoming Quotient version, same for Itinerary/Poppler. I'm fine with break-things-early if we have a fix-things-early outcome from it :) Cheers, Albert > The only thing we > are missing for those fixes to take effect is those dependencies bumping > their version numbers. > > We could work around that by doing configure-time detection using a compile > test, but that's a lot of extra work, so we'd better try to address this > upstream first. > > I'd very much suggest the use of release tarballs (or stable branches) for > apps that aren't continuously monitoring their dependencies this way though, > but I'm not aware we have such a case. > > Regards, > Volker
Re: KDE Gear projects with failing CI (master) (21 January 2025)
On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben Cooksley wrote: > On Thu, Jan 23, 2025 at 5:49 AM Volker Krause wrote: > > On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit Albert > > > > Astals Cid wrote: > > > neochat - NEW > > > > > > * https://invent.kde.org/network/neochat/-/pipelines/869365 > > > > > > * flatpak build fails > > > > Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I > > guess, > > looks like an API change in libQuotient with the corresponding version > > change > > still pending (ie. a similar problem we occasionally hit with Poppler). > > > > The quick solution for this would probably be (temporarily) switching > > Flatpak > > to the latest release of libQuotient. The IMHO proper solution would be to > > have version bumps at the beginning of a development cycle that changes > > API. > > This also raises another question though - should we be strongly > discouraging use of heavily moving targets like upstream dev / master > branches and instead favouring the use of stable branches? > Not really ideal if upstream can essentially break our builds without us > doing anything. I can't comment on NeoChat, but for Itinerary the builds against the latest versions of essential (external) dependencies with varying intentions/success in keeping backward compatibility (ZXing, Poppler, Quotient) are very much deliberate, to catch breakage/regressions early (same as we are now doing for KF with Qt pre-releases). And this is actually working, NeoChat has been fixed to build with the upcoming Quotient version, same for Itinerary/Poppler. The only thing we are missing for those fixes to take effect is those dependencies bumping their version numbers. We could work around that by doing configure-time detection using a compile test, but that's a lot of extra work, so we'd better try to address this upstream first. I'd very much suggest the use of release tarballs (or stable branches) for apps that aren't continuously monitoring their dependencies this way though, but I'm not aware we have such a case. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: End of life policy
El dimecres, 22 de gener del 2025, a les 4:35:53 (Hora estàndard del Centre d’Europa), rhkra...@gmail.com va escriure: > On Tuesday, January 21, 2025 05:16:25 PM Albert Astals Cid wrote: > > Is it not a consequence from the fact that there's no more releases > > planned? > > > > It's weird to say "for things that we don't plan releases there will no be > > releases" > > > > What would you write? > > From the peanut gallery: How about: > > No more releases planned for this project. > > and perhaps, in parenthesis after that, something like (end of project) But we're not speaking about end of project. We are speaking about the fact that Okular 24.12.x is not going to be released anymore because Okular 25.04.x is the next release series, not that we're not going to release Okular at all anymore. Cheers, Albert
Re: End of life policy
Jan 22, 2025 18:44:08 Justin Zobel : > 1. How long/which version (tied together as our releases are done at regular > intervals) do we support each release for things KDE produces, e.g. Gear, > Plasma, Frameworks? > > 2. Document this information clearly on our Wiki. We could add a little more detail to https://community.kde.org/Schedules. We could at least add something under "Previous Releases by KDE" that those releases will not get any more bugfixes. As Albert said: >It's weird to say "for things that we don't plan releases there will no be >releases" and yet it might help some people understand if we were a little more explicit.
