Sven Van Caekenberghe wrote:

On 08 Feb 2012, at 11:42, Schwab,Wilhelm K wrote:

...

Ok, but what about 1.3? Is 1.4 "ready" - last word was to use 1.3, which has some troubles too.

Active Pharo development is happing on the unstable branch, 1.4. Pharo 1.3 was released a long time ago, as a freeze of the development branch, and after a period of RC testing. Sometimes critical patches are backported from 1.4 to 1.3, but often that is not possible, it is also a lot of work for the integrators.

Sven

This is probably a naive view, but I was wondering it the effort of backporting critical patches could be reduced if the development process went... Rather than as I understand it, current 1.3 is frozen and the live trunk continues as unstable 1.4 mixing both planned refactoring and unplanned bug fixes discovered in 1.3. It then takes additional effort to implement those fixes in 1.3 where they were discovered. Not withstanding the ideal of release candidate testing finding these bugs, the reality is that people properly migrate between versions at different rates. Using the stable version for day-in-day-out for weeks on end does exercise code differently than artificial testing during RC phase. Alternatively, 1.3 could be kept the main live version on the continuation integration server. A core developer's local 1.4 refactoring is uploaded to the CI server as a changeset against the live 1.3 version. When this changeset tests okay, it is available to be pulled down by other core developers to update their image. Thus bugs discovered in 1.3 can be fixed in 1.3 and also flow through to 1.4 with the 1.4 refactoring isolated from the 1.3 bug fixes. It is a bit presumptuous of me to be suggesting such changes to the core development process, but my ideas fight me to get out. Perhaps I'll learn something when I get shot down :) On the downside, the added complexity of such a process may introduced additional incremental effort which exceeds the effort backporting selected bug fixes. regards, -ben

Stef, There are things in 1.4 that I will eventually like, but for now, it is very difficult to use. I had a code holder get dragged and dropped from a browser to the desktop and couldn't get a halo to kill it. Context menus don't work well and lack the polish of earlier versions. My problem is that 1.3 does not appear to be able to break processes, and once Metacello gets running, I lose the ability to open debuggers and process browsers. It is (sorry) basically unusable. On the up side, I did some useful work on Migrate and my 1.1.1 image looks GREAT as a result. Preference changes broke some of my code, and it took me a while to see how to recover those abilities. I now have nice fonts and can much more easily read source :) I will be in a fairly good position as 1.4 stabilizes, but for now, I can't get 1.3 or 1.4 to cooperate. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, February 08, 2012 7:39 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fixed to interrupt behavior 1.4 is stable but we are working on it. STef On Feb 8, 2012, at 11:42 AM, Schwab,Wilhelm K wrote:

Ok, but what about 1.3? Is 1.4 "ready" - last word was to use 1.3, which has some troubles too.

________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Marcus Denker [marcus.denker@inria.fr] Sent: Wednesday, February 08, 2012 5:24 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fixed to interrupt behavior

On Feb 8, 2012, at 11:22 AM, Schwab,Wilhelm K wrote:

...

Stef,

We are on the same topic then. I am having problems with cmd . on 1.3 - it won't break anything :(

it is fixed in 1.4.

Marcus

-- Marcus Denker -- http://marcusdenker.de