Release Plan

Andreas Pakulat apaku at gmx.de
Mon Oct 20 15:58:21 UTC 2008


On 20.10.08 10:30:13, Matt Rogers wrote:
> On Sunday 19 October 2008 04:23:23 Andreas Pakulat wrote:
> > On 19.10.08 10:02:50, M Breugelmans wrote:
> > > On Sat, Oct 18, 2008 at 10:11 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> > > > Hi,
> > > >
> > > > until further notice the KDE 4.2 Release Schedule is used for the
> > > > tagging dates. That means that I won't do the tagging myself, but will
> > > > rely on Dirk to do it. I'll just increase the version numbers before
> > > > the tagging.
> > > >
> > > > So Alpha3 will be tagged on monday, 21st.
> > > >
> > > > The schedule is here:
> > > > http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule
> > >
> > > Can you explain a bit how this influences commits? I think adymo said
> > > something earlier about exempt from feature freeze?
> >
> > It doesn't. We're still in alpha-release state, which means we have no
> > freezes, no matter what the KDE release schedule says. At the point where
> > we decide to do our first beta, we'll have a hard feature freeze. That
> > means all unfinished features need to be backed out/disabled and we're
> > going to fix all the bugs (this includes ui-fixes of course). I'm not yet
> > sure wether we'll release Beta1 at the end of January next year, that
> > depends on our progress in the next 2.3 months. In any way a beta1 will be
> > announced here about 4 weeks before the actual freeze+tagging, so there'll
> > be enough "warning time" :)
> >
> 
> So if we've started a feature, we don't get time to finish it? That's not even 
> how the KDE release schedule works.

Actually, it works exactly like that. The Soft Feature Freeze starts with
the first Alpha-Release, i.e. tomorrow. From that time on, no new feature
can be started. Then at some point there's the first beta, at that point in
time your feature must be complete, it may contain bugs, but the
functionality needs to be there - or it needs to be removed again until
trunk is unfrozen. 

> If you start new features before the hard 
> feature freeze, then we should have the opportunity to finish/bugfix the 
> features, IMO.

Bugfixing can always be done, apart from that as I said the Hard Feature
freeze and hence the Beta1 will be announced early enough. So this won't
actually be a problem. The point in time when this is announced is our soft
feature freeze, from that point on no new feature may be started in either
of the modules, only the already started ones may be finished. Same thing
as with the KDE release cycle, except that our plan isn't as long-term as
the KDE one. We can always talk about the time-frame between announcing the
Beta1 tagging date/hard feature freeze and the actual date of the tagging
(i.e. 4 weeks in advance or 6, probably not more as that would be too much)

> > So thats what my plans are currently, anybody who has different
> > opinions/suggestions feel free to speak up.
> 
> We can always keep releasing alpha snapshots until we're comfortable.

Of course we will do that, I wasn't putting any hard dates so far, however
I think we all need to concentrate more on getting the stuff done thats
needed for the initial 4.0 release, instead of indefinetly pushing out
alpha's that are rc's in some parts and pre-alpha's in other parts.

Andreas

-- 
Do what comes naturally.  Seethe and fume and throw a tantrum.




More information about the KDevelop-devel mailing list