On Wed, 12 Sep 2018 09:44:21 -0400, you wrote:
On Wed, Sep 12, 2018 at 9:34 AM Rex Dieter
<rdieter(a)math.unl.edu> wrote:
>
> Matthew Miller wrote:
>
> > On Wed, Sep 12, 2018 at 12:27:03AM +0200, Luigi Toscano wrote:
> >> It does not make sense to do it for Frameworks (which is always keeping
> >> the API), nor for the bundle known as KDE Applications (where you want
> >> the last version), nor for the applications which independent release
> >> schedule (Krita, Krusader, Tellico, etc; same as KDE Applications).
> >
> > One thing that you could do, if you want, is only maintain a single branch
> > and spec file for each of these which would build across all current
> > supported releases...
>
> Now that part does sound appealing, is essentially what we do for plasma
> releases already by hand.
>
We could technically do this now simply by ignoring the other branches
and just tell fedpkg to kick off builds against the master branch all
the time. Modules do not solve this specific problem. Allowing us to
use fedpkg to push to multiple releases simultaneously without work
would help more.
My (possibly incorrect) understanding is the modules, being a form of
container like Docker, would allow you to include say a library
version different than provided by the underlying Fedora installation.
So it would make it possible to say ship the latest Krita on all
versions of Fedora even if a library it requires version X of is at
X-1 on the previous Fedora release(s).
While this isn't so much an issue for any KDE sig maintained libraries
it could be an issue for other libraries.