[Pharo-project] Actions done in 1.3

Igor Stasenko siguctua at gmail.com
Wed Apr 6 22:57:22 CEST 2011

On 6 April 2011 22:32, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <laurent.laffont at gmail.com>
> wrote:
>> On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <siguctua at gmail.com> 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.

More information about the Pharo-project mailing list