[Pharo-project] Actions done in 1.3

Eliot Miranda eliot.miranda at gmail.com
Wed Apr 6 22:32:48 CEST 2011


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.

best
Eliot


>
> Always green test is a must-have.
>
>
>
>> Besides bug fixing and minor improvements, there should be some
>> functionality which we want to have in new release,
>>
>
> That should be a goal, but don't delay a release because the feature is not
> here. If releases are often ( for example every 3 months), shorter, it won't
> be a big problem to wait for the next one.
>
> I prefer to have a release *now* without my feature and wait 3 months for
> the next release than no release and waiting for 3 months more with less and
> less energy.
>
>
> Laurent.
>
>
>> so then you could say: 1.x is better than previous because of A,B,C,
>> but not because a,b,c  ( capital letters is major stuff, while regular
>> ones is for minor stuff ) :)
>>
>>
>> On 6 April 2011 10:01, Serge Stinckwich <serge.stinckwich at gmail.com>
>> wrote:
>> > On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont
>> > <laurent.laffont at gmail.com> wrote:
>> >> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck
>> >> <marianopeck at gmail.com> wrote:
>> >>>
>> >>> Yes!!! totally agree.  Now that we release 1.2, I would freeze and
>> release
>> >>> PharoCore 1.3 beta.  Update the link to stable pharo to that, and
>> start
>> >>> trying to load the dev tools there.
>> >>
>> >> +10
>> >> And propose a fixed date for release - no compromise, will be release
>> at
>> >> this date.
>> >
>> > +1
>> > Timeboxing sounds great.
>> > Podomoro for software development ;-)
>> >
>> > Regards,
>> > --
>> > Serge Stinckwich
>> > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>> > Every DSL ends up being Smalltalk
>> > http://doesnotunderstand.org/
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110406/239f28ad/attachment.htm>


More information about the Pharo-project mailing list