Releases in 3 months

Luigi Toscano luigi.toscano at tiscali.it
Wed Jul 10 17:26:55 BST 2013


On Wednesday 10 of July 2013 18:08:04 Àlex Fiestas wrote:
> On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote:
> > On 2013-07-09, Sune Vuorela <nospam at vuorela.dk> wrote:
> > > So. first one.
> > 
> > Second one
> > 
> > Release frequency.
> > 
> > We have a giant quality problem. Distros won't ship a .0 release to real
> > users (as opposed to testers/power users) and wait until there has been
> > a couple of bug fix releases. Until we ensure that our .0 releases are
> > usable I don't see how we can cut down on that.
> > 
> > Some distros release in a 6 month cycle. Others in a 8. and ones even in
> > longer cycles. Going for anything shorter than 6 months will ensure that
> > distros are going to skip releases. why work with releases that they
> > aren't going to ship to users anyways?
> 
> Not by distributions working that way I guess.
> 
> Part of the reasons why I want this release schedule is exactly for these
> distros. Let me explain.
> 
> Right now distributions pick the release they see fit and make a distro with
> it. It might be .0, .2 or .5.
> 
> If a distribution in their right decide to pick a .5 release wile a .0 is
> already out there (this already happened), what is happening here is that a
> HUGE release with a LOT of changes won't even get to the users of that
> distribution at least for another distribution cycle. This usually happens
> with distributions that have a release cycle of 9 months.

The Linux kernel itself maintain old branches with big number of point 
releases. See 3.0.85, 3.2.48, 3.4.52, done by kernel developers.


> [...]
> > And as it currently is, we need the .4 and .5 releases.
> 
> and .6 and .7 and .8 and .9, we could have a 4.0.200, there is always need
> of bugfixing releases, question is how many of these point releases are
> pending of upstream KDE and not downstream distros.
> 
> To make it clear, I WANT to have .4 and .5 releases, just not made by
> upstream developers.

Uhm... are you sure this will work? It can work for paid contributors, but not 
for unpaid ones. Moreover, this means that it's fine if users don't receive 
the last version, which was one of your goals stated above:
> With having releases every 3 months we make the amount of features smaller
> and more often so distributions will always be able to pick a more updated
> release than with the current situation.

Ciao
-- 
Luigi





More information about the kde-core-devel mailing list