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?
I guess Marcels question was also about testing release scripts, though. So maybe we should have some credentials for uploading to squeakvm.org 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?
Am 01.08.2016 5:57 nachm. schrieb "Tim Felgentreff" < timfelgentreff@gmail.com>:
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)
Am 01.08.2016 16:16 schrieb "Ben Coman" btc@openinworld.com:
The workflow I referred to *does* merge into master, but only after actual Release, not before. It allows bleeding edge to proceed on the Cog branch while have a stable reference point while organising the Release. This seems useful, but I've not had a chance to use that workflow myself, so I'll say no more on it :)
cheers -ben
On Mon, Aug 1, 2016 at 8:22 PM, Fabio Niephaus lists@fniephaus.com wrote:
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.
Cheers, Fabio
--
On Sun, Jul 31, 2016 at 1:17 PM Ben Coman btc@openinworld.com wrote:
On Sun, Jul 31, 2016 at 2:42 PM, marcel.taeumel Marcel.Taeumel@hpi.de
wrote:
Hi, there.
Could some please tag some VM version as "stable" so that we have the
first
candidate to be used in the Squeak release artifact packaging
process? :-) I
don't want to package any latest "bleeding edge" VM build into those artifacts.
Thanks, Marcel
Would there be a benefit in a release workflow like suggested under the heading "Release branches" [1] ? (where their 'develop' branch is effectively our 'Cog' branch)
[1] http://nvie.com/posts/a-successful-git-branching-model/
cheers -ben
vm-dev@lists.squeakfoundation.org