<p dir="ltr">No Fabio, the intepreter vm is on the &#39;old trunk&#39; branch, master is identical to cog at the time of import (or maybe two commits later) </p>
<div class="gmail_extra"><br><div class="gmail_quote">Am 01.08.2016 16:16 schrieb &quot;Ben Coman&quot; &lt;<a href="mailto:btc@openinworld.com">btc@openinworld.com</a>&gt;:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The workflow I referred to *does* merge into master, but only after<br>
actual Release, not before.  It allows bleeding edge to proceed on the<br>
Cog branch while have a stable reference point while organising the<br>
Release.  This seems useful, but I&#39;ve not had a chance to use that<br>
workflow myself, so I&#39;ll say no more on it :)<br>
<br>
cheers -ben<br>
<br>
On Mon, Aug 1, 2016 at 8:22 PM, Fabio Niephaus &lt;<a href="mailto:lists@fniephaus.com">lists@fniephaus.com</a>&gt; wrote:<br>
&gt;<br>
&gt; AFAIR we wanted to merge the Cog branch into master and then tag the master for a new release. The main question I guess is: when is the right moment to do this? IIRC Eliot has used his gut feeling in the past for declaring a specific version as stable. So I&#39;d say it&#39;s up to him to decide when the first stable release on GitHub is ready.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Fabio<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; On Sun, Jul 31, 2016 at 1:17 PM Ben Coman &lt;<a href="mailto:btc@openinworld.com">btc@openinworld.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Sun, Jul 31, 2016 at 2:42 PM, marcel.taeumel &lt;<a href="mailto:Marcel.Taeumel@hpi.de">Marcel.Taeumel@hpi.de</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Hi, there.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Could some please tag some VM version as &quot;stable&quot; so that we have the first<br>
&gt;&gt; &gt; candidate to be used in the Squeak release artifact packaging process? :-) I<br>
&gt;&gt; &gt; don&#39;t want to package any latest &quot;bleeding edge&quot; VM build into those<br>
&gt;&gt; &gt; artifacts.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks,<br>
&gt;&gt; &gt; Marcel<br>
&gt;&gt;<br>
&gt;&gt; Would there be a benefit in a release workflow like suggested under<br>
&gt;&gt; the heading &quot;Release branches&quot; [1] ?   (where their &#39;develop&#39; branch<br>
&gt;&gt; is effectively our &#39;Cog&#39; branch)<br>
&gt;&gt;<br>
&gt;&gt; [1] <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="noreferrer" target="_blank">http://nvie.com/posts/a-successful-git-branching-model/</a><br>
&gt;&gt;<br>
&gt;&gt; cheers -ben<br>
&gt;<br>
&gt;<br>
</blockquote></div></div>