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
-- View this message in context: http://forum.world.st/Marking-VMs-as-stable-tp4908814.html Sent from the Squeak VM mailing list archive at Nabble.com.
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
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
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...
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 <
btc@
> wrote:
On Sun, Jul 31, 2016 at 2:42 PM, marcel.taeumel <
Marcel.Taeumel@
>
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
-- View this message in context: http://forum.world.st/Marking-VMs-as-stable-tp4908814p4909001.html Sent from the Squeak VM mailing list archive at Nabble.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
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
-
Ben Coman -
Fabio Niephaus -
marcel.taeumel -
Tim Felgentreff