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 |
On Sun, Jul 31, 2016 at 2:42 PM, marcel.taeumel <[hidden email]> 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 |
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 <[hidden email]> wrote:
|
Actually, I forgot that the interpretervm currently lives on the master branch. So we'd either need to merge Cog into master and produce a spur interpretervm now, or we could move the interpretervm from master to a new branch and defer this task... -- On Mon, Aug 1, 2016 at 2:22 PM Fabio Niephaus <[hidden email]> wrote:
|
In reply to this post by fniephaus
We should just use *some* version so we can program our release automation scripts for it. We can always find a more stable version in the future. Best, Marcel |
In reply to this post by fniephaus
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 <[hidden email]> 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 <[hidden email]> wrote: >> >> >> On Sun, Jul 31, 2016 at 2:42 PM, marcel.taeumel <[hidden email]> 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 > > |
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" <[hidden email]>:
|
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" <[hidden email]>:
|
Free forum by Nabble | Edit this page |