> On 16 Jan 2016, at 12:12, stepharo <[email protected]> wrote: >>> On 16 Jan 2016, at 02:42, Ben Coman <[email protected]> wrote: >>> >>> So if occasionally if everything seems against you, after trying a >>> fresh Image as you already did, slide back to the last build that >>> worked for you (I don't think the issues you experience are Spur >>> related, but 50496 might be a good fallback as Pre-Spur and >>> Pre-GTDebugger). Then create a fresh Image from the latest build to >>> test your Slice and in that time maybe the other issues have gone. >> Ok. So my earlier question (in Slack, I think) about how "unstable" is >> unstable in Pharo is now answered. It's really unstable, not "Debian-like >> unstable". > > No this is not really the case. In general we try hard to get alpha stable > after you get some hiccups. > This is not every day that we change FFI, GC, object internal representations > and the text editors, syntax highli > And our problems is that sometimes often we just jump over glitches (this is > why I'm getting mad because when I do videos > or other I see them in my face). Now I would love to have task forces that > check glitches.
I get the picture now. I just checked in when the lobby, the roof and the plumbing of the hotel were undergoing renovations: it's not how it is usually. I could question whether it's a good idea to cram so much in a single release cycle. But release management is a difficult topic, and often there is no good solution, just one that has less downsides than the others. Cheers.
