[Vm-dev] Marking VMs as "stable"

[Ben Coman]

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 at 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 at openinworld.com> wrote:
>>
>>
>> On Sun, Jul 31, 2016 at 2:42 PM, marcel.taeumel <Marcel.Taeumel at 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
>
>