Release Plan

[Matt Rogers]

On Monday 20 October 2008 10:58:21 Andreas Pakulat wrote:
> 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.
>

That's an oversimplification. After the KDE soft feature freeze, the feature 
list is frozen and only new features that are on the feature list can be 
added. You can still add new features, as long as they're on the list. When 
the hard feature freeze hit, then there's no features that can be started but 
those that are already present can be bugfixed.

> > 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)
>

Personally, I think we should follow the exact same steps that the main KDE 
modules do, some of which I've clarified above. 


> > > 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

And that is what? 
-- 
Matt