Re: [Pharo-project] Actions done in 1.3
On Apr 5, 2011, at 9:10 PM, Stéphane Ducasse wrote:
Hi guys
to help us in the future I started
http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotThree
The list starts to get long...
Maybe we should do a 1.3 release soon... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
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. Cheers Mariano On Tue, Apr 5, 2011 at 10:39 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On Apr 5, 2011, at 9:10 PM, Stéphane Ducasse wrote:
Hi guys
to help us in the future I started
http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotThree
The list starts to get long...
Maybe we should do a 1.3 release soon...
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Mariano http://marianopeck.wordpress.com
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. Laurent.
Cheers
Mariano
On Tue, Apr 5, 2011 at 10:39 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On Apr 5, 2011, at 9:10 PM, Stéphane Ducasse wrote:
Hi guys
to help us in the future I started
http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotThree
The list starts to get long...
Maybe we should do a 1.3 release soon...
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Mariano http://marianopeck.wordpress.com
ok for me. Stef
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.
Laurent.
Cheers
Mariano
On Tue, Apr 5, 2011 at 10:39 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Apr 5, 2011, at 9:10 PM, Stéphane Ducasse wrote:
Hi guys
to help us in the future I started
http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotThree
The list starts to get long...
Maybe we should do a 1.3 release soon...
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Mariano http://marianopeck.wordpress.com
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/
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. Besides bug fixing and minor improvements, there should be some functionality which we want to have in new release, 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.
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. 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.
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.
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.
best Eliot
(...)
Best regards, CdAB
On Wed, Apr 6, 2011 at 1:52 PM, Casimiro de Almeida Barreto < casimiro.barreto@gmail.com> 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
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 <casimiro.barreto@gmail.com> 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
On 6 April 2011 22:32, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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.
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.
participants (8)
-
Casimiro de Almeida Barreto -
Eliot Miranda -
Igor Stasenko -
laurent laffont -
Marcus Denker -
Mariano Martinez Peck -
Serge Stinckwich -
Stéphane Ducasse