On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <laurent.laffont@gmail.com> wrote:

On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <siguctua@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@gmail.com> wrote:
> On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont
> <laurent.laffont@gmail.com> wrote:
>> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck
>> <marianopeck@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.