[Pharo-project] Three current versions: 1.0, 1.1, 1.2
I hear that we're working on 1.2 now. But pharo-project.org still hands out 1.0 versions to everyone who asks. So we'll get plenty of bug reports for 1.0. I think we should switch over to 1.1 on the home page soon. Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
On Jun 8, 2010, at 10:28 AM, Niko Schwarz wrote:
I hear that we're working on 1.2 now. But pharo-project.org still hands out 1.0 versions to everyone who asks. So we'll get plenty of bug reports for 1.0.
I think we should switch over to 1.1 on the home page soon.
1.2 has not yet started. the idea is to do the 1.1 switch before... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Niko, Are you suggesting denying access to 1.0? IMHO, stable releases should be available "forever," though a couple of extra steps, such as going to an archive and hunting would be reasonable. If you are suggesting that we encourage the use of 1.1, then we need to do something like a second beta or at least an RC. I grabbed the most recent core and was quite impressed (can't live w/o shout though). The ConnectionQueue bug was marked as critical to 1.1. I agree that it needs to be fixed, and dropping the true return value as suggested might be the most direct approach. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Niko Schwarz [niko.schwarz@googlemail.com] Sent: Tuesday, June 08, 2010 4:28 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Three current versions: 1.0, 1.1, 1.2 I hear that we're working on 1.2 now. But pharo-project.org still hands out 1.0 versions to everyone who asks. So we'll get plenty of bug reports for 1.0. I think we should switch over to 1.1 on the home page soon. Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Of course not. Just switch the default download (the big one, all over the site) site to 1.1. I just suggest to switch from 1.0 to 1.1 as stable at the same time that we switch from 1.1 to 1.2 for development. Then we never have 3 "current" versions at once. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
On Tue, Jun 8, 2010 at 9:46 AM, Niko Schwarz <niko.schwarz@googlemail.com>wrote:
Of course not. Just switch the default download (the big one, all over the site) site to 1.1.
I just suggest to switch from 1.0 to 1.1 as stable at the same time that we switch from 1.1 to 1.2 for development.
I think this is a good idea.
Then we never have 3 "current" versions at once.
Cheers,
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think it's a bad idea to just switch the downloads from 1.0 to 1.1 now. We don't even have a release candidate yet, hence 1.1 hasn't seen much testing. 1.1 may be ok for personal use but is it also safe to be deployed on a mission critical system? I'm all for short release cycles, but please don't take such shortcuts. A high quality is really important if we want to support the companies using Pharo and attract new ones. So the next steps should be: identifying the critical issues (currently there are 179 open issues tagged 1.1!), then fixing them, then we do a first RC. Cheers, Adrian On Jun 8, 2010, at 15:45 , Mariano Martinez Peck wrote:
On Tue, Jun 8, 2010 at 9:46 AM, Niko Schwarz <niko.schwarz@googlemail.com>wrote:
Of course not. Just switch the default download (the big one, all over the site) site to 1.1.
I just suggest to switch from 1.0 to 1.1 as stable at the same time that we switch from 1.1 to 1.2 for development.
I think this is a good idea.
Then we never have 3 "current" versions at once.
Cheers,
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
_______________________________________________ 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
+1 -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Tuesday, June 08, 2010 1:53 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Three current versions: 1.0, 1.1, 1.2 I think it's a bad idea to just switch the downloads from 1.0 to 1.1 now. We don't even have a release candidate yet, hence 1.1 hasn't seen much testing. 1.1 may be ok for personal use but is it also safe to be deployed on a mission critical system? I'm all for short release cycles, but please don't take such shortcuts. A high quality is really important if we want to support the companies using Pharo and attract new ones. So the next steps should be: identifying the critical issues (currently there are 179 open issues tagged 1.1!), then fixing them, then we do a first RC. Cheers, Adrian On Jun 8, 2010, at 15:45 , Mariano Martinez Peck wrote:
On Tue, Jun 8, 2010 at 9:46 AM, Niko Schwarz <niko.schwarz@googlemail.com>wrote:
Of course not. Just switch the default download (the big one, all over the site) site to 1.1.
I just suggest to switch from 1.0 to 1.1 as stable at the same time that we switch from 1.1 to 1.2 for development.
I think this is a good idea.
Then we never have 3 "current" versions at once.
Cheers,
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jun 8, 2010, at 8:53 PM, Adrian Lienhard wrote:
I think it's a bad idea to just switch the downloads from 1.0 to 1.1 now. We don't even have a release candidate yet, hence 1.1 hasn't seen much testing. 1.1 may be ok for personal use but is it also safe to be deployed on a mission critical system? I'm all for short release cycles, but please don't take such shortcuts. A high quality is really important if we want to support the companies using Pharo and attract new ones.
We can keep 1.0 download but we will issue 1.1 rc now.
So the next steps should be: identifying the critical issues (currently there are 179 open issues tagged 1.1!), then fixing them, then we do a first RC. We will not fix all these issues but moved them to 1.2. Since most of them exit in 1.0 and you can work with them I do not see why suddenly we should fix them in 1.1 especially just before the release. So stability also means that you should not change the system at wrong moment. And now this is not the moment to change it.
Stef
Cheers, Adrian
On Jun 8, 2010, at 15:45 , Mariano Martinez Peck wrote:
On Tue, Jun 8, 2010 at 9:46 AM, Niko Schwarz <niko.schwarz@googlemail.com>wrote:
Of course not. Just switch the default download (the big one, all over the site) site to 1.1.
I just suggest to switch from 1.0 to 1.1 as stable at the same time that we switch from 1.1 to 1.2 for development.
I think this is a good idea.
Then we never have 3 "current" versions at once.
Cheers,
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, I think you misunderstood me. I didn't imply that we need to fix the 179 issues for 1.1. But what we should really do is to identify whether there is any show stopper. I started going through the 1.1-tagged issues yesterday and I have moved stuff that is not critical to 1.2 (or close what doesn't need any further action). Maybe it would be better not to tag issues with 1.2 unless we know that we want to take them into account for 1.2. Else we end up being in the same situation as now. Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now. Cheers, Adrian On Jun 9, 2010, at 08:03 , Stéphane Ducasse wrote:
On Jun 8, 2010, at 8:53 PM, Adrian Lienhard wrote:
I think it's a bad idea to just switch the downloads from 1.0 to 1.1 now. We don't even have a release candidate yet, hence 1.1 hasn't seen much testing. 1.1 may be ok for personal use but is it also safe to be deployed on a mission critical system? I'm all for short release cycles, but please don't take such shortcuts. A high quality is really important if we want to support the companies using Pharo and attract new ones.
We can keep 1.0 download but we will issue 1.1 rc now.
So the next steps should be: identifying the critical issues (currently there are 179 open issues tagged 1.1!), then fixing them, then we do a first RC. We will not fix all these issues but moved them to 1.2. Since most of them exit in 1.0 and you can work with them I do not see why suddenly we should fix them in 1.1 especially just before the release. So stability also means that you should not change the system at wrong moment. And now this is not the moment to change it.
Stef
Cheers, Adrian
On Jun 8, 2010, at 15:45 , Mariano Martinez Peck wrote:
On Tue, Jun 8, 2010 at 9:46 AM, Niko Schwarz <niko.schwarz@googlemail.com>wrote:
Of course not. Just switch the default download (the big one, all over the site) site to 1.1.
I just suggest to switch from 1.0 to 1.1 as stable at the same time that we switch from 1.1 to 1.2 for development.
I think this is a good idea.
Then we never have 3 "current" versions at once.
Cheers,
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
_______________________________________________ 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
_______________________________________________ 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 Jun 9, 2010, at 9:29 16AM, Adrian Lienhard wrote:
Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now.
Cheers, Adrian
- ConnectionQueue. (2476) - WeakKeyDictionaries. Easiest would probably be to port the one in Squeak now (with related finalization classes), as Levente did some work on that compared to what was in Squeak 4.0 / Pharo 1.0 which made it faster without breaking it when not registered for finalization. Alternatively wait for VM's to be built with Igor's finalization enhancements, require those for 1.1 WeakRegistries, and rewrite WeakKeyDictionaries to no longer assume they may be used/are always registered for finalization. (1628, 2309) - Encoding for code importing/exporting (setConverterForCode methods 1608 , 1872) Cheers, Henry
adrian there are some fixed simple UTF and other pending fixes that we could integrate (was planning for after lunch) Stef
Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now.
Cheers, Adrian
- ConnectionQueue. (2476) - WeakKeyDictionaries. Easiest would probably be to port the one in Squeak now (with related finalization classes), as Levente did some work on that compared to what was in Squeak 4.0 / Pharo 1.0 which made it faster without breaking it when not registered for finalization. Alternatively wait for VM's to be built with Igor's finalization enhancements, require those for 1.1 WeakRegistries, and rewrite WeakKeyDictionaries to no longer assume they may be used/are always registered for finalization. (1628, 2309) - Encoding for code importing/exporting (setConverterForCode methods 1608 , 1872)
are some fixed? Stef
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jun 9, 2010, at 11:38 39AM, Stéphane Ducasse wrote:
adrian there are some fixed simple UTF and other pending fixes that we could integrate (was planning for after lunch) Stef
Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now.
Cheers, Adrian
- ConnectionQueue. (2476) - WeakKeyDictionaries. Easiest would probably be to port the one in Squeak now (with related finalization classes), as Levente did some work on that compared to what was in Squeak 4.0 / Pharo 1.0 which made it faster without breaking it when not registered for finalization. Alternatively wait for VM's to be built with Igor's finalization enhancements, require those for 1.1 WeakRegistries, and rewrite WeakKeyDictionaries to no longer assume they may be used/are always registered for finalization. (1628, 2309) - Encoding for code importing/exporting (setConverterForCode methods 1608 , 1872)
are some fixed?
Stef
No, he asked for important things that _needs_ to be fixed :) 1st is a regression from 1.0. 2nd I explained a few approaches to "fixing". 3rd is not a regression from 1.0, but still a blatant problem for anyone expecting to be able to write their code in anything but ascii, and be able to reliably export/import it somewhere else. Whether it is a blocking issue or not, I suppose depends on whom you ask. Cheers, Henry
On Jun 9, 2010, at 12:15 PM, Henrik Johansen wrote:
On Jun 9, 2010, at 11:38 39AM, Stéphane Ducasse wrote:
adrian there are some fixed simple UTF and other pending fixes that we could integrate (was planning for after lunch) Stef
Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now.
Cheers, Adrian
- ConnectionQueue. (2476) - WeakKeyDictionaries. Easiest would probably be to port the one in Squeak now (with related finalization classes), as Levente did some work on that compared to what was in Squeak 4.0 / Pharo 1.0 which made it faster without breaking it when not registered for finalization. Alternatively wait for VM's to be built with Igor's finalization enhancements, require those for 1.1 WeakRegistries, and rewrite WeakKeyDictionaries to no longer assume they may be used/are always registered for finalization. (1628, 2309) - Encoding for code importing/exporting (setConverterForCode methods 1608 , 1872)
are some fixed?
Stef
No, he asked for important things that _needs_ to be fixed :) 1st is a regression from 1.0. 2nd I explained a few approaches to "fixing". 3rd is not a regression from 1.0, but still a blatant problem for anyone expecting to be able to write their code in anything but ascii, and be able to reliably export/import it somewhere else. Whether it is a blocking issue or not, I suppose depends on whom you ask.
I will tag all the ones you mentioned as 1.1.... so we can assess. The idea is that not releasing 1.1 because of a bug that was already in 1.0 makes no sense. E.g. it means that everyone already using 1.0 did not find it a grave problem for *months*, so I am sure people can wait for 1.2 to have it fixed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On Jun 9, 2010, at 9:29 AM, Adrian Lienhard wrote:
Stef, I think you misunderstood me. I didn't imply that we need to fix the 179 issues for 1.1. But what we should really do is to identify whether there is any show stopper.
sure :)
I started going through the 1.1-tagged issues yesterday and I have moved stuff that is not critical to 1.2 (or close what doesn't need any further action).
Yes I saw and I started to do that a while ago too.
Maybe it would be better not to tag issues with 1.2 unless we know that we want to take them into account for 1.2. Else we end up being in the same situation as now.
may be :)
Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now.
Cheers, Adrian
On Jun 9, 2010, at 08:03 , Stéphane Ducasse wrote:
On Jun 8, 2010, at 8:53 PM, Adrian Lienhard wrote:
I think it's a bad idea to just switch the downloads from 1.0 to 1.1 now. We don't even have a release candidate yet, hence 1.1 hasn't seen much testing. 1.1 may be ok for personal use but is it also safe to be deployed on a mission critical system? I'm all for short release cycles, but please don't take such shortcuts. A high quality is really important if we want to support the companies using Pharo and attract new ones.
We can keep 1.0 download but we will issue 1.1 rc now.
So the next steps should be: identifying the critical issues (currently there are 179 open issues tagged 1.1!), then fixing them, then we do a first RC. We will not fix all these issues but moved them to 1.2. Since most of them exit in 1.0 and you can work with them I do not see why suddenly we should fix them in 1.1 especially just before the release. So stability also means that you should not change the system at wrong moment. And now this is not the moment to change it.
Stef
Cheers, Adrian
On Jun 8, 2010, at 15:45 , Mariano Martinez Peck wrote:
On Tue, Jun 8, 2010 at 9:46 AM, Niko Schwarz <niko.schwarz@googlemail.com>wrote:
Of course not. Just switch the default download (the big one, all over the site) site to 1.1.
I just suggest to switch from 1.0 to 1.1 as stable at the same time that we switch from 1.1 to 1.2 for development.
I think this is a good idea.
Then we never have 3 "current" versions at once.
Cheers,
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jun 9, 2010 at 9:29 AM, Adrian Lienhard <adi@netstyle.ch> wrote:
Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now.
I think http://code.google.com/p/pharo/issues/detail?id=2469 should be integrated before 1.1. I remember how much of a pain the simulator behavior was when messing with SUnit. Toon's patch might be the foundation for cleaner SUnit code. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683
On Jun 9, 2010, at 1:34 PM, Niko Schwarz wrote:
On Wed, Jun 9, 2010 at 9:29 AM, Adrian Lienhard <adi@netstyle.ch> wrote:
Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now.
I think http://code.google.com/p/pharo/issues/detail?id=2469 should be integrated before 1.1. I remember how much of a pain the simulator behavior was when messing with SUnit. Toon's patch might be the foundation for cleaner SUnit code.
I added that. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On Wed, Jun 9, 2010 at 1:34 PM, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
On Wed, Jun 9, 2010 at 9:29 AM, Adrian Lienhard <adi@netstyle.ch> wrote:
Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now.
I think http://code.google.com/p/pharo/issues/detail?id=2469 should be integrated before 1.1. I remember how much of a pain the simulator behavior was when messing with SUnit. Toon's patch might be the foundation for cleaner SUnit code.
I added it... I wonder if that was a good idea. Now we have failing tests: http://code.google.com/p/pharo/issues/detail?id=2546 Marcus -- -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
participants (7)
-
Adrian Lienhard -
Henrik Johansen -
Marcus Denker -
Mariano Martinez Peck -
Niko Schwarz -
Schwab,Wilhelm K -
Stéphane Ducasse