Marking VMs as "stable"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Marking VMs as "stable"

marcel.taeumel
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
Reply | Threaded
Open this post in threaded view
|

Re: Marking VMs as "stable"

Ben Coman
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Marking VMs as "stable"

fniephaus
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Marking VMs as "stable"

fniephaus
 
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:
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
Reply | Threaded
Open this post in threaded view
|

Re: Marking VMs as "stable"

marcel.taeumel
In reply to this post by fniephaus
fniephaus 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
>
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
Reply | Threaded
Open this post in threaded view
|

Re: Marking VMs as "stable"

Ben Coman
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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Marking VMs as "stable"

timfelgentreff
 

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]>:

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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Marking VMs as "stable"

timfelgentreff
 

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]>:

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]>:

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
>
>