<p dir="ltr">What I wanted to do was set it up that any tag on master is turned into a named release... I think Fabio has done some work on this to make the Vm version include the tag name, but I'm not sure how far along that is. Maybe it's all ready? In that case Eliot could open a PR from Cog to master when/if he feels its fairly stable, we wait till it's green, and then merge an push a tag to master?</p>
<p dir="ltr">I guess Marcels question was also about testing release scripts, though. So maybe we should have some credentials for uploading to <a href="http://squeakvm.org">squeakvm.org</a> and other places and encrypt those with Travis' public key, so we can also automate uploading the "latest stable" version in a visible place for each of the projects that uses the VM? </p>
<div class="gmail_extra"><br><div class="gmail_quote">Am 01.08.2016 5:57 nachm. schrieb "Tim Felgentreff" <<a href="mailto:timfelgentreff@gmail.com">timfelgentreff@gmail.com</a>>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">No Fabio, the intepreter vm is on the 'old trunk' branch, master is identical to cog at the time of import (or maybe two commits later) </p><div class="elided-text">
<div class="gmail_extra"><br><div class="gmail_quote">Am 01.08.2016 16:16 schrieb "Ben Coman" <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>>:<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've not had a chance to use that<br>
workflow myself, so I'll say no more on it :)<br>
<br>
cheers -ben<br>
<br>
On Mon, Aug 1, 2016 at 8:22 PM, Fabio Niephaus <<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>> wrote:<br>
><br>
> 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'd say it's up to him to decide when the first stable release on GitHub is ready.<br>
><br>
> Cheers,<br>
> Fabio<br>
><br>
> --<br>
><br>
> On Sun, Jul 31, 2016 at 1:17 PM Ben Coman <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>> wrote:<br>
>><br>
>><br>
>> On Sun, Jul 31, 2016 at 2:42 PM, marcel.taeumel <<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>> wrote:<br>
>> ><br>
>> > Hi, there.<br>
>> ><br>
>> > Could some please tag some VM version as "stable" so that we have the first<br>
>> > candidate to be used in the Squeak release artifact packaging process? :-) I<br>
>> > don't want to package any latest "bleeding edge" VM build into those<br>
>> > artifacts.<br>
>> ><br>
>> > Thanks,<br>
>> > Marcel<br>
>><br>
>> Would there be a benefit in a release workflow like suggested under<br>
>> the heading "Release branches" [1] ? (where their 'develop' branch<br>
>> is effectively our 'Cog' branch)<br>
>><br>
>> [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>
>><br>
>> cheers -ben<br>
><br>
><br>
</blockquote></div></div>
</div></blockquote></div><br></div>