On 6 April 2011 22:32, Eliot Miranda <[email protected]> wrote: > > > On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <[email protected]> > wrote: >> >> On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <[email protected]> wrote: >>> >>> Planning is also important. >>> >>> Time is good, but another thing is i think we should think about, >>> what features we want to be in new release, and do not release until >>> they delivered. >> >> I don't really like this. I prefer rhythm, agility. Timeboxing enables >> maximum value in each release. If a feature is really important, it will be >> on time. If not on time, it means it was no so important. > > I couldn't disagree more. Especially with VisualWorks time-boxing has > caused problems with quality and delivery of functionality. Fundamentally > there is no point putting out a release for the sake of it. A release is > about functionality, both new functionality and bug fixes. Without either > of these there is absolutely no point in releasing anything beyond > marketing. Yes, during a release one can make the call that because a > subset of the functionality will arrive much later than the rest of the > functionality it makes sense for that late functionality to slip the release > and arrive in a later one. But that doesn't imply putting out an > essentially empty release for the sake of promptness.
> One thing I do approve of is maintennance releases, where some time after an > initial release one puts out a maintennance release that only contains bug > fixes and no new functionality and I think there are good arguments for and > positive experience with scheduling the maintennance release to arrive at > some fixed time after the first release, e.g. 4 to 6 months. But major > releases must IMO be driven by content. Right. That's exactly what i wanted to say. There's no point to make a release of a 'new version' if it doesn't contains a functionality which were planned to include. Maintenance is sufficient for this. -- Best regards, Igor Stasenko AKA sig.
