We have here ambitious plan for 2015.0, and believe me we should move all focus on cooker asap. 2014.1 is a bugfix release, of 2014.0 and doing some artifical delays because some software is going to be released in few months is very bad idead, because there always will be some new software released which we should include in our iso. Following this loging we will fall into rolling-release model which, means that it will be hard to release anything.
Bero is right here so +1 2014-07-20 15:45 GMT+02:00 Bernhard Rosenkraenzer <[email protected]>: > On 2014-07-20 15:01, Kate Lebedeff wrote: > > Hi all >> >> If I may a small Q >> >> Why can't we finish things now - but release them a bit later? >> > > > We could -- but technology gets obsolete really fast - if we did that, it > would just end up being a "boring" release ("they come out with a KDE > 4.13.x thing now even though 4.14 is out? That sucks..."). > > I think there's a good point to be made for sticking with the original > release plan (release what we have so we can move on to our 2015.0 plans - > or we'll end up not getting things done because we've spent too much time > on 2014.x releases), and there's a good point to be made for doing a later > release with newer stuff as well (given 2015.0 will almost certainly be KDE > 5.x based, it would be good to have a solid release with the last KDE 4.x > release -- which would be 4.14). > > Marketing-wise, the point about many people being on vacation at end of > July is real, but OTOH everyone is thinking of that and not making releases > in that time frame, so we could get the undivided attention of those > staying at home. > > I don't think there's much of a point in artificially delaying a release > that is ready now by another month -- people will just see it as an > "obsolete before it was released" thing, and it'll make people install > 2014.0 rather than a release with lots of bugfixes since then for another > month (possibly getting a bad first impression if they happen to run into > one of the bugs we fixed). (Besides, we're perfectionists - I'm pretty sure > we'd still end up fixing it even though it's supposed to be done). > > ttyl > bero >
