I do not have specific stance on that this is why I hear both arguments.
Now agility is not something that we claim but that we do.
I think that not having releases that drag on forever is important.
I prefer to have
- 3/4 releases full of energy that are time based vs. 2 that are
slugglish and ends up in few fixes over a long period.
- this would avoid to have an accumulation of code to integrate and
laucnh beta too early to reduce the pressure.
- In addition since people do not understand what is a release
candidate, then having more frequent release would mean
that people port more often if they want.
So we will see. For now the good point is that we can release 1.3 tomorrow and
this will not be a release maintenance because
lot of changes are already done.
Stef
On Apr 6, 2011, at 11:40 PM, Eliot Miranda wrote:
>
>
> On Wed, Apr 6, 2011 at 1:52 PM, Casimiro de Almeida Barreto
> <[email protected]> wrote:
> Em 06-04-2011 17:32, Eliot Miranda escreveu:
>>
>>
>>
>> (...)
>>
>>
>> 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.
> +1 Here
>
>>
>> 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.
> +1 Here but...
>
> I think that maintenance releases must be presented in the form of "software
> updates" (meaning, no need to install a new image & reinstall everything in
> it). Ideally it should be possible to upgrade fixes without breaking what's
> working.
>
> Agreed. What I said about maintennance releases was rather 20th century of
> me. Forget I ever mentioned it :)
>
>>
>> best
>> Eliot
>>
>> (...)
>>
> Best regards,
>
> CdAB
>
