<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Ben,<br><br></div><div><br>On Jun 19, 2017, at 9:01 AM, Ben Coman <<a href="mailto:btc@openinworld.com">btc@openinworld.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 2:05 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>So please, let's make sure that the VM continues to function unchanged for existing images.</div></div></div></div></blockquote><div><br></div><div>Is it too gratuitous to bump the image version to define existing images?</div><div>Or not practical anyway?</div></div></div></div></div></blockquote><div><br></div>IMO this is something that one does only on a major release such as the Squeak 4.x to 5.0 and Pharo 5 to Pharo 6 V3 to Spur transition. The VM should strive to be backward compatible, whereas images are forwards compatible. This allows the VM to be upgraded to fix bugs & add new functionality. And this policy is achievable in practice. IME, both VisualWorks' HPS and Cog and the Squeak interpreter VM (& I'm sure other Smalltalk VMs) have always provided this approach.<div><br></div><div><br></div><div>I don't see the providing of a setting to enable high dpi as a good reason for changing the VM version mid-stream, with all the inconvenience for users that this implies:</div><div><br></div><div>For users, they have to maintain two VMs and the ability to launch them plus being able to tell which is which; easier for users of Pharo launcher, but not something to be complicated unnecessarily.</div><div><br></div><div>For VM maintainers dropping backwards compatibility implies adding another VM to maintain and back port fixes to. It's already costly to maintain the V3/Spur VMs (e.g. adding the allocated bytes accounting for Spur requires a guard clause to avoid impacting the V3 vm). So we have to keep the matrix to a minimum.</div><div><br></div><div>I'm happy to expand the matrix for experiments that look like offering my a large future payoff such as Sista and Lowcode (& indeed Spur) and to continue to support older versions for as long as we as a community think make sense. But we should avoid doing this wherever possible. Resources dictate.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>cheers -ben </div></div></div></div>
</blockquote></div></body></html>