Future frameworks releases

[Christian Mollekopf]

On Wednesday 17 June 2015 23.01:41 Kevin Ottens wrote:
> Hello,
> 

Hey,

> 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.
> 

Alright, something that I'll need to address then.

> > 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. :-)
> 

Alright, that's fine then. I think I have to be a bit obstinate in this 
situation, but I really don't want to piss people off, which is sometimes
difficult to handle via email.

> 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.
> 

Indeed.

> > 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.
> 

Ok, with that I can agree. I'm glad to hear you're opinion isn't set in stone
on that topic, because that's what I (mistakenly) extracted from your previous 
responses.

> > > [*] 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.
> 

Since I'm currently swamped with work I'll have to put this on the back-burner 
for the moment, and as suggested we can pick this up during akademy.

Until then I can also do some more preparation to explain the specific 
requirements better, and with that we can hopefully devise a solution that 
works for everyone.

Cheers,
Christian


> 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.