No more release schedules.

[Tom Albers]

----- Original Message -----
> Seriously, though, you can still publish a KDE *SC* 4.8 (or 5.0 or
> whatever)
> and a corresponding release schedule called exactly that.

I think it is even more confusing to release kde sc 4.8 with for example, platform 5, pim 4.7 and plasma 2. What exactly does 4.8 stand for in that case?

> This is absolutely true. Creating distro packages from such a version
> mix will
> become a nightmare. Not to speak of the problem that there will not
> be a
> common "KDE SC experience" across all distros anymore but a pretty
> much random
> collection of modules according to the individual release plans of
> both
> modules and distros. (Not to speak of us source-based distros with
> "rolling
> releases".)

I doubt the release schedule can keep that together. If the platform releases version 5, distro's need to package it and then ship 4 too and some kde modules will be compatible with platform 5 and some won't ever. So, however we turn it, I see we can add some structure, but I do think that structure needs to be set on a per module base, no longer on a central base.

> Even today, some distros have either not even started working on the
> 4.7 beta
> because of the comparedly small mess we're already facing today. My
> guess is
> that those alphas (at different milestones) won't get much testing at
> all
> because we, as packagers, will likely have a hard time puzzling all
> the pieces
> together properly - and some of us most likely won't even bother to
> try.

Sure, and we can see a 'deadlock' in this mailinglist with that subject. Some packagers are ok with splitting, some want it consistent and some want it monolotic. I think the module maintainers should have a bigger role and responsibility here, as there can not be one guy on this list which decides all this.

I'm very concerned about the 4.7 release tbh, because I don't see a solution appearing while we need one asap. Maybe if we split it up and have responsible 'leaders' for each module we can prevent such situations and have a better uniform communication.

> So, if they don't like to work toward it, there won't be unified KDE
> SC
> releases anymore? And even if there are, there will be only *two*
> releases a
> year? I'd consider that a *major* step beackwards.

2 or also for all the minor release of just 12 release moments a year, that was not the point. That are details...

> > > Coordinate? We *create* releases and manage them.
> > We can still package and release them if you like, that's
> > independent of
> > the schedules.
> 
> Uhm... No? *What* are you going to package? How are you going to make
> sure
> whatever you decide to package is actually going to work with the
> other
> modules? Of course, you can randomly pick some date, package and
> release
> whatever is available at that point but, from a QA point of view,
> this might
> not be the wisest approach to release engineering.

Well, it's up to the module maintainers to work out the release schedule to reach a stable release at the release point. I think that will work fine. We won't go randomly tarball some random folder. 

Thanks for the mail. It helps to clarify this idea better. 

Best,
-- 
Tom Albers
KDE Sysadmin