[Pharo-project] Fwd: to go beta?
Marcus, Adrian, Mike how do we proceed to go beta? take the 1.0 fixes and integrate them. put a deadline and do it?
Stef
That's a good question I was also thinking about today... I suggest the following steps: 1. Review all issues in the tracker and decide for each whether it is important for 1.0. 2. We concentrate on completing these 1.0-tagged items. New issues should only be tagged with 1.0 if they are critical bugs (i.e., no new improvements get integrated anymore!) 3. As soon as we have completed all items that change the behavior of the system (i.e., that are not bugfixes) we declare beta 4. As soon as all items are done, we declare gamma and after a while without newly reported problems we release 1.0 Adrian On Jun 11, 2009, at 21:59 , Stéphane Ducasse wrote:
Marcus, Adrian, Mike how do we proceed to go beta? take the 1.0 fixes and integrate them. put a deadline and do it?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I will try to rewrite this week the last dirty method (according to my count)... so the 1.0 should be license clean... . After this maybe I could help with some bugs. On Thu, Jun 11, 2009 at 5:19 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
That's a good question I was also thinking about today...
I suggest the following steps:
1. Review all issues in the tracker and decide for each whether it is important for 1.0. 2. We concentrate on completing these 1.0-tagged items. New issues should only be tagged with 1.0 if they are critical bugs (i.e., no new improvements get integrated anymore!) 3. As soon as we have completed all items that change the behavior of the system (i.e., that are not bugfixes) we declare beta 4. As soon as all items are done, we declare gamma and after a while without newly reported problems we release 1.0
Adrian
On Jun 11, 2009, at 21:59 , Stéphane Ducasse wrote:
Marcus, Adrian, Mike how do we proceed to go beta? take the 1.0 fixes and integrate them. put a deadline and do it?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Jun 12, 2009 at 3:19 AM, Adrian Lienhard<adi@netstyle.ch> wrote:
That's a good question I was also thinking about today...
I suggest the following steps:
1. Review all issues in the tracker and decide for each whether it is important for 1.0. 2. We concentrate on completing these 1.0-tagged items. New issues should only be tagged with 1.0 if they are critical bugs (i.e., no new improvements get integrated anymore!) 3. As soon as we have completed all items that change the behavior of the system (i.e., that are not bugfixes) we declare beta 4. As soon as all items are done, we declare gamma and after a while without newly reported problems we release 1.0
What could be great is a release during next ESUG conference in september. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
On 11.06.2009, at 16:19, Adrian Lienhard wrote:
That's a good question I was also thinking about today...
I suggest the following steps:
1. Review all issues in the tracker and decide for each whether it is important for 1.0. 2. We concentrate on completing these 1.0-tagged items. New issues should only be tagged with 1.0 if they are critical bugs (i.e., no new improvements get integrated anymore!) 3. As soon as we have completed all items that change the behavior of the system (i.e., that are not bugfixes) we declare beta 4. As soon as all items are done, we declare gamma and after a while without newly reported problems we release 1.0
Yes, that makes sense. I did a pass over the last days to close / harvest the most simple small changes (e.g. small cleanups). We are down to 257 open bug reports. Marcus
participants (5)
-
Adrian Lienhard -
Gabriel Cotelli -
Marcus Denker -
Serge Stinckwich -
Stéphane Ducasse