[kde-promo] Plasma Next Naming - Take 2

[Martin Gräßlin]

On Monday 27 January 2014 15:14:46 Sebastian Kügler wrote:
> On Monday, January 27, 2014 15:05:43 Jos Poortvliet wrote:
> > >  * Inside Plasma team, we'll start referring to the next version simply
> > >  as
> > > 
> > > "Plasma Next". This will always be the "next major version to be
> > > released".
> > > We encourage everyone to start using "Plasma Next", we don't want this
> > > to
> > > be inside-thing only
> > 
> > Hmmm, it makes sense as temporary solution until we have a release date
> > (the  role Plasma 2 is fulfilling atm) but I'm not sure if it doesn't just
> > add unneeded clutter to our message. Once we know there will be a plasma
> > 2014.06, we can just call it that, right?
> 
> The concern here is that we're not sure we'll be able to deliver every
> release in time.
> 
> Although, thinking of it, I think in the past 6 years, we missed exactly one
> planned release, by two weeks. Going by that experience, as long as we plan
> to release in the first two weeks of a given month, we should be fine. :)
Looking at other projects (I think here of a large distribution which I do not 
want to name which releases in April and October) we can see that having the 
date set in stone can be problematic. They release in the month and have no 
chance at all to add more time. There have been several cases when it would 
have been useful for them to have more time as for example demonstrated in 
13.10 as they pulled back a large tech transition in last minute (not that I 
mind that...)

I do not want us to restrict ourselves and make our own life harder just 
because we want to stick to a random chosen date. We should never end up in a 
situation that we don't want to extend the cycle because of that. We should 
never release in a worse state than should be acceptable just because we want 
to release in month "foo".

I remember several cases where we had issues which were not large enough to 
stop the rolling of all of KDE SC, but there were certainly enough issues 
which should have stopped a Plasma release. So I do hope that we use this 
chance of the decoupling and don't add new random constraints making our life 
harder :-)

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140127/b354bb26/attachment.sig>