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