Post 2.0.0 release plan discussion

[Ian Monroe]

On Thu, Nov 20, 2008 at 3:17 PM, Seb Ruiz <ruiz at kde.org> wrote:
> 2008/11/21 Nikolaj Hald Nielsen <nhnfreespirit at gmail.com>:
>> The main point is that we should do a number of very fast 2.0.x bugfix
>> releases. A sane proposal would be do to 2 3 week release cycles ( 2
>> weeks development, 1 week freeze ) for 2.0.1 and 2.0.2. This will
>> allow us to quickly respond to the worst bugs that show up after the
>> final is released.
>
> We've always had a rather lax idea of "freeze", especially during the
> 1.3/1.4 series, and I think this added a positive contribution to the
> huge development we saw then. I feel that our post 2.0 freeze, whilst
> necessary to a great degree, restricted a lot of developers and their
> coding habits (although git has alieved lots of these). For this
> reason I think we should drop from freeze threat level red to freeze
> threat level yellow - allow new features and strings, provided they
> are small enough and don't include large risky changes.
>

Just seconding this. Mostly I don't think it should be a feature
freeze at all, but a refactoring freeze or in general freeze on things
that are liable to cause a regression. Obviously thats somewhat of a
judgment call, but I think each of us has some sense of how risky each
change we make is.

The start of 1.2/1.3 and part of 1.4 had very rapid releases. Lots of
cool features were added in these rapid releases, as well as bug
fixes. The cover manager was such a feature added in a minor release.
:)

2.0 is pretty unique though, so I'd be open to the idea of branching
2.0 and working 2.1 sooner then previous major releases. But we can
cross that road when we get there.

On Thu, Nov 20, 2008 at 1:24 PM, Soren Harward <stharward at gmail.com> wrote:
> On Thursday 20 November 2008 12:38:47 Lydia Pintscher wrote:
>> So first of all please everyone let me/us know about their post 2.0
>> plans. No bikesheding and/or discussion here! Just tell what you want
>> to work on. Brainstorming! Everything is allowed.
>
> I have the acoustic similarity feature and a completely new Automatic Playlist
> Generator subsystem ready to be committed when feature freeze is lifted.

So this is a good example of what I mean. Given that we have no
acoustic similarity features, it could very well be possible to
introduce such features regression free (assuming its reasonably
modular). Worse case if it turns out to not be ready, it can be
removed.

However we already have a dynamic playlist feature that works great,
so a "completely new Automatic Playlist Generator subsystem" is rather
scary! Last we discussed you didn't have a UI that was as easy to use
as the current one, so it would be a UI regression even if worked as
hoped.

Ian