Future frameworks releases

[Kevin Ottens]

Hello,

On Tuesday 16 June 2015 11:14:28 Christian Mollekopf wrote:
> On Tue, Jun 9, 2015, at 10:32 PM, Kevin Ottens wrote:
> Sorry for the late response.

No worries, it's not like I'm very responsive either. I didn't manage to 
participate properly on the k-f-d discussion on that topic for a start. ;-)
 
> > On Tuesday 09 June 2015 10:08:06 Christian Mollekopf wrote:
> > > On Monday 08 June 2015 18:47:06 Kevin Ottens wrote:
> > A use case trumped by... one person (AFAIC). Really when I look at the
> > thread here and the thread on k-f-d I only see you pushing hard for it and
> > almost everyone else moaning.
> 
> True, I just wanted to make clear that this is not only about making me
> happy, and I tried to lay out clearly why there are technical reasons why a
> library should be versioned individually.

Sure. I think some arguments were left behind though. I might be wrong, but I 
think the "well, Qt does the same and it's apparently not a problem" wasn't 
properly addressed.

> While I personally believe versioning the libraries individually is the
> right thing, I could see why I'm the only one pushing in that direction
> because I'm the only one (in this discussion), that also has a professional
> responsibility

I don't think I agree there, you're not the only one with professional 
constraint toward KF5.

> in that regard and a special usecase because we're using those libraries
> also on servers. So not your typical desktop usecase.

That OTOH, it's extremely likely that you're the only one indeed.

> [...]
> Well, I really hoped to convince come people in that discussion, or to
> get my own opinion adjusted by technical reasons I didn't foresee. Neither
> happened which made this whole discussion a rather frustrating exercise.

Sorry about that as I clearly added to the frustration.

> I know I pushed this hard, and I did so because I think it's an important
> topic, and because I think it's for the best of frameworks, and not only me.
> But I have no intent of being disrespectful, so if that's what came across
> then I'm sorry.

I don't think you've been disrespectful. I guess that was the limit of my 
metaphor which carried this feeling... turns out my footnote was better in 
that regard. You've been obstinate though, but clearly you've not been alone 
with that trait. :-)

Right now, I think the problem is that we have two parties running in circle 
not being able to convince each other and no mechanism in place to deal with 
that.

> I meant to say that I think it would be a more reasonable default to
> have all libraries versioned independently, and simply bump the ones
> automatically that don't want this (which still may be the majority),
> for lack of manpower/maintainer reasons. But I was clearly a bit
> frustrated at that point, sorry.

BTW, I'd like to point out, because I think was not clear in that regard 
earlier. That personally I don't mind if we decide single version vs multiple 
versions. I see pros and cons in both.

What I'd like though is that either we go in one direction (different versions 
as the norm), or the other (status quo), but we don't go for "A, B and C do 
that while X, Y, Z does something else". It's what I tried to point with 
"weird exceptions" earlier and failed.

> > [*] Note I'm not saying such customs are then frozen. Since a new person
> > joined, which will create new interations, after a while the customs will
> > change gradually. The kitchen might even get reorganized in the end but
> > for sure in a very different way than if I rushed in with my own
> > preconceived ideas.[**]
> 
> I'm glad to hear that. Until then I guess my options are limited:
> * I can keep kimap out of frameworks, but that doesn't buy me a whole
> lot as I still rely on other frameworks, and most of the PIM libraries
> really ought to be frameworks. So I'm not inclined to do that.

As I said earlier I don't like that much either, I'm glad you're not 
contemplating it despite the amount of sometimes extreme negativity.

> * I can maintain versioned branches for all frameworks I need, which is
> going to be a PITA, but at least for me only.
> This is likely what's going to happen until we can adjust the versioning
> policy somehow from by POV.

If we don't manage to devise something consistent upfront I think that's a 
path. With the "running in circles" I was mentioning earlier that might be for 
the time being the practical path.

I think that's the case because this way we'll see your work in those branches 
and that might help document and understand the pains you're mentioning and we 
can't seem to be able to understand at the moment.


Now, among all the noise in both threads, I'd be surprised if we don't have a 
proper solution hiding somewhere, we likely have the pieces but not properly 
put together.

Bear with me I'll be partly acting from memory here... let's see something 
like:
 1) KF5 releases are numbered YYYY.MM;
 2) Individual frameworks are numbered 5.N, N being incremented only if 
there's been commits since the last KF5 release;
 3) Each KF5 release directory contains tarballs of all the frameworks in 
their latest version.

(1) and (2) would decouple completely the collection numbering from the 
individual frameworks numbering and would open the door to what you ask as a 
rule not an exception. That should allow different version numbers between the 
frameworks while avoiding the confusion of a collection version 5.20 
containing frameworks in version 5.12. We avoid that proximity altogether, 
since no one would be surprised of the collection 2016.02 containing a 
framework in version 5.12 another one in version 5.15, etc.

I guess (2) would need to be tuned to David's and your liking. So that N is 
bumped for each framework in a way that please you both[*] (higher priority), 
ideally in a way where it can be expressed as a uniform rule for all 
frameworks.

(3) should cater the need of users wanting to pick a working subset of 
frameworks. The argument was "easy they all have the same number", it becomes 
"easy they all are in the same directory". Not as powerful but good enough I 
would say.
(3) should also cater the packagers needs or inqlude needs as it's basically 
listing the folder[**]. If needed a manifest file as you discussed could be 
generated in the folder too.

Now I feel like it'll be arguing about (2)... but at least we get a chance of 
being more focused.

Regards.

[*] Note that IMO, that tuning should not involve going toward 5.N.M version 
scheme. The 5.N only scheme was intentional and debated quite a bit already. 
It's intentional to have a combination of very short cycles and feature + 
bugfix on each releases. Packagers were skeptic about it but it's been proven 
to work now.

[**] A problem I see with the idea of sometimes not putting a framework in a 
release directory is that it makes it harder to do that properly or at least 
more error prone.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20150617/a3e24b0c/attachment.sig>