Release Cycle

Aaron J. Seigo aseigo at kde.org
Mon Aug 19 23:17:18 UTC 2013


On Tuesday, August 20, 2013 00:24:53 Albert Astals Cid wrote:
> El Dilluns, 19 d'agost de 2013, a les 22:18:26, Aaron J. Seigo va escriure:
> > On Monday, August 19, 2013 22:14:26 Albert Astals Cid wrote:
> > > There will be a 4.13? Most probably.
> > > Will it be in 2014? For sure
> > > Which month? Noone knows, you can probably guess it'll be between Q2 and
> > > Q3
> > > since Q1 would mean <= 3 months of development and Q4 would mean >= 10
> > > months.
> > 
> > unless we change the development cycle, which has not yet been done, which
> > month will 4.13 be in?
> 
> Are you disagreeing with the 4.12 schedule?

No; however, on http://techbase.kde.org/Schedules/KDE4/4.12_Release_Schedule 
it says “THIS IS NOT OFFICIAL YET” four times right at the top. I was under 
the impression that it was still being discussed and wasn’t ... you know .. 
official yet.

Perhaps it is official already, and 4.12 is going to be release in December. If 
so, then the promo team should be able to tell the world that.

If it isn’t decided then what might work best is to communicate 4.12/4.13 in 
January and August respectively (as per Jos’ list) but add a footnote that 
after 5 years of steady 6 month releases, the release engineering team is 
investigating quicker release cycles and how they might improve quality and 
delivery. As such those dates should be considered provisional and may be 
revised earlier once the release team completes its efforts.

If the 4.12 schedule as proposed is not accepted, then jan/aug is accurate.

If the 4.12 schedule as proposed is accepted, then the date revisions happen.

In both cases, the public communication reflects the state of things and tells 
the world we do have schedules as well as a planning mechanism behind them.

Essentially, I’m suggesting that we don’t:

* say nothing
* say that we don’t know what we’re doing (or phrasing that will be 
interpreted that way)

It has become increasingly valued by 3rd parties and downstreams to feel that 
they can have confidence in upstream having a plan. KDE got harassed pretty 
badly for a while because we had rather functional ~9 month cycles with cycle-
to-cycle flexibility and that was not (in the eyes of 3rd parties) predictable 
enough, therefore KDE could not be trusted due to lacking coordination.

Since then everyone has worked hard to improve on that and thanks to years of 
steady releases, including the monthly updates, our reputation in this area 
has improved considerably. We would be wise to preserve that.

-- 
Aaron J. Seigo
-------------- 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/release-team/attachments/20130820/b170703f/attachment.sig>


More information about the release-team mailing list