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. 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 <[email protected]> >> wrote: >> > On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont >> > <[email protected]> wrote: >> >> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck >> >> <[email protected]> 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. >> >> >
