Future frameworks releases

[Michael Pyne]

On Mon, June 8, 2015 22:29:16 Mario Fux wrote:
> Am Montag, 08. Juni 2015, 17.21:56 schrieb Benjamin Reed:
> 
> Morning
> 
> > On 6/8/15 11:02 AM, Eric Hameleers wrote:
> > > The only sane way forward is that every Frameworks release contains
> > > all Frameworks tarballs, regardless of updates since the previous
> > > public release. Every Framework should adhere to the overall version
> > > number.
> > 
> > Yeah, this proposal makes no sense to me.
> 
> Then please read the thread on kde-frameworks-devel as there is some sense
> in this proposal. We might decide against it in the end but to say that it
> doesn't make sense is just not valid.
> 
> > If you want to individually
> > manage a library with an independent numbering scheme, then shouldn't it
> > be a separate/external project?  The whole point of the "framework" is
> > to provide a monolithic thing that has everything you need.
> 
> Either I don't get this sarcasm or you might be wrong.
> 
> "The whole point" of KDE Frameworks is that it is _modular_ and not
> monolithic as kdelibs was. As I see it the value of KDE Frameworks is the
> set of Qt Addons with a unique license and spreading over different
> platforms. A high quality set of additional features and libraries for Qt
> developers from developers with a lot of experience.

The modularity is only to a point. For instance a Tier 3 framework module at 
version x.y is allowed to depend on a version x.y of any Tier 1 or 2 framework 
modules being installed, without any special capability checks. So while you 
could in theory distribute a kdefoo x.y (Tier 2) that dependss on kdebar x.y 
(Tier 1), a distributor distributing kdefoo x.y could not be packaged with 
kdebar x.(y-1) (even if kdebar didn't actually change).

Bumping the installed version of a Tier 1 KDE framework module would require 
bumping the version of all installed higher-tier framework modules.

I think that something like this came up some months ago when the packagers 
had requested that we distribute KF5 with more granularity (and especially, 
with a "stable" branch as proposed for KImap here) and the result was that 
we'd refused, and instead opted for the current scheme where KF5 is tagged 
essentially all together based on the reviewed code merged into master.

There were good reasons for that decision, though I don't remember the details 
at this point.

Regards,
 - Michael Pyne