Re: [Pharo-project] Silly Tweet
On Jun 30, 2011, at 9:57 AM, Fernando Olivero wrote:
Why do people still use an older image? Even as older as Pharo1.1 and 1.2.
It doesn't take much to update to Pharo1.3 or Pharo1.4, and its totally worth the nuisance of updating a couple of classes references and uses, because of the many many many improvements that get integrated ( thanks for Marcus and Stef for the continuos improvements integration and fixes)
In a commercial setting, things are different... people need to really think hard to move to a new system. Time is money, bugs are expensive, there is always a deadline more important... One thing we want to do with Pharo over the next years is to actually make it easy to stay at an old version. And easy to gradually move to new versions. It's an interesting question how a language and system can support software evolution *for real*. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On Jun 30, 2011, at 10:15 , Marcus Denker wrote:
On Jun 30, 2011, at 9:57 AM, Fernando Olivero wrote:
Why do people still use an older image? Even as older as Pharo1.1 and 1.2.
It doesn't take much to update to Pharo1.3 or Pharo1.4, and its totally worth the nuisance of updating a couple of classes references and uses, because of the many many many improvements that get integrated ( thanks for Marcus and Stef for the continuos improvements integration and fixes)
In a commercial setting, things are different... people need to really think hard to move to a new system. Time is money, bugs are expensive, there is always a deadline more important...
Exactly. When you have systems of the size >1000 classes that have been grown over years and have to work reliably, just "updating a couple of classes [sic] references and uses" is not easy. First of all, you have to figure out *what* to change. Changes like a modified Dictionary/Set hierarchy can subtly break your code (leading to data corruption in our case [1]). Or, just because you are one of the first to use the new code under high load, you see problems others haven't seen before (leading to unresponsive images in our case [2]). Those are obvious external bugs, but we also ran into issues with our code just not being compatible anymore with new semantics (e.g., Number class>>#readFrom:). That's why in a non-trivial setup, upgrading is costly, and at times painful (in particular when you missed problems in testing and then experience them in production). [1] http://code.google.com/p/pharo/issues/detail?id=3658 [2] http://code.google.com/p/pharo/issues/detail?id=3498 Cheers, Adrian
It has been suggested that package maintainers should run their own CI server to track changes of their package on older images. That seems eminently reasonable. What would be hugely helpful for that would be a script or tar-file downloadable from the Pharo CI server for each image version (historical and current) that one (such as me) could download and get running with minimal information about the arcane knowledge required for configuring Hudson/Jenkins. Then I could easily track my package's compatibility with legacy images and decide when I am willing to break with e.g. 1.1 compatibility for my package. I know this would take a chunk of time for somebody, but I suggest it would be time well spent because it lets the main CI server concentrate on the current version, but supports package maintainers moving forward with their packages. ../Dave
participants (3)
-
Adrian Lienhard -
Dave Mason -
Marcus Denker