Em 10/01/2010 18:30, Mariano Martinez Peck <marianopeck@gmail.com> escreveu:
On Sun, Jan 10, 2010 at 9:10 PM, <csrabak@bol.com.br> wrote: [snipped]
I'm not so sure if I undertand this in full, so I'll test my understanding: Do your assertion above means that an hypothetical:
Pharo1.0-10505-rc1dev10.01.1 that after some updates ends up reponding in System->About this:
Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510
You say that it would be *different* than a brand new downloaded: Pharo1.0-10510-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510 Is it?
Exactly. Maybe is just a little detail. I don't know.
[snipped]
As an after thought after seeing other posts on the issue, I think more than a generic warning that "may break the image" the Monticello comments and/or a simple explanation on the reasons and affected packages *before* the update starts with an option to proceed or abort is much in need.
Yes, maybe. Then thing is that I am not sure in which cases it would break. Only in overrides? How many overrides do we have from external pacakges in Core stuff? I have no idea.
Considering both comments above, I would say we're going to have a not cool system. If this non determinism is left in our updating mechanism, more and more we'll have bug reports answered as "could not reproduce" or similar and the perceived quality of Pharo as a programming tool will suffer. I understand the issue isn't small potatoes but we should keep it in mind and find all opportunities to have this streamlined. As a counter measure, a built image could have a kind of history log of changesets zeroed and as one applies updates, slices, and load packages, this info could become available (as an adjunct to the debug trace) to help to backtrack the steps to reproduce the reported issue. HTH -- Cesar Rabak PS.: Before Stef puts a line asking for code, I believe we already have the machinary for this available, if this is not the case, then we'll need to put code in!