- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1419: 22702-support-before-after-intead-on-RBCascadeNode

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1419 was: SUCCESS. The Pull Request #2018 was integrated: "22702-support-before-after-intead-on-RBCascadeNode" Pull request url: https://github.com/pharo-project/pharo/pull/2018 Issue Url: https://pharo.fogbugz.com/f/cases/22702 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 28, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

Ah, I forget to say that this change we enter in effect today :) May the force be with us. Esteban > On 28 Nov 2018, at 12:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Ok, a new pass onto this, I decided that having just dev-Etc. branches and not having a clear stable one may lead to confusion. > After checking some projects on GitHub, seems that what they do is to name their branches just with the version, not with âdevâ (like, for example "gtk-2.22â). > > So, I will name the version based branchs âPharo7.0â, âPharo8.0â and so on. > > (Without dash to keep coherence with the artefact naming) > > Cheers! > Esteban > > >> On 22 Nov 2018, at 13:25, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> >>> On 22 Nov 2018, at 13:21, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> >>> >>>> On 22 Nov 2018, at 12:48, Christophe Demarey <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> wrote: >>>> >>>> Hi, >>>> >>>> Why not following git flow? >>>> Keep the development branch for dev and open a 70-release branch to prepare the release. >>>> This way, there is no change for most people. >>> >>> Because our scripts are automated in branch and tag basis. >>> dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate a release. >>> >>> We could have another flow, but this was what we decided last week and we will try it (maybe this is wrong and we will need to change it, but wellâ¦ weâll seeâ¦ good part of having a process is that we can iterate on it :P) >> >> Btw, Iâm not complete happy with this either: as it is previewed now, there will not be stable branch, and I feel this is incorrect. But againâ¦ good thing is we can iterate, weâll see if this works. >> >> Esteban >> >>> >>> Esteban >>> >>>> >>>> Christophe >>>> >>>>> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >>>>> >>>>> Hi list, >>>>> >>>>> Well, subject says pretty much all. >>>>> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >>>>> Then, it will be a âdev-8.0â and so onâ¦ >>>>> >>>>> So, be prepared to submit your PRs to dev-7.0 instead development :) >>>>> >>>>> Cheers, >>>>> Esteban >

Nov. 28, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

Ok, a new pass onto this, I decided that having just dev-Etc. branches and not having a clear stable one may lead to confusion. After checking some projects on GitHub, seems that what they do is to name their branches just with the version, not with âdevâ (like, for example "gtk-2.22â). So, I will name the version based branchs âPharo7.0â, âPharo8.0â and so on. (Without dash to keep coherence with the artefact naming) Cheers! Esteban > On 22 Nov 2018, at 13:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 22 Nov 2018, at 13:21, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> >>> On 22 Nov 2018, at 12:48, Christophe Demarey <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> wrote: >>> >>> Hi, >>> >>> Why not following git flow? >>> Keep the development branch for dev and open a 70-release branch to prepare the release. >>> This way, there is no change for most people. >> >> Because our scripts are automated in branch and tag basis. >> dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate a release. >> >> We could have another flow, but this was what we decided last week and we will try it (maybe this is wrong and we will need to change it, but wellâ¦ weâll seeâ¦ good part of having a process is that we can iterate on it :P) > > Btw, Iâm not complete happy with this either: as it is previewed now, there will not be stable branch, and I feel this is incorrect. But againâ¦ good thing is we can iterate, weâll see if this works. > > Esteban > >> >> Esteban >> >>> >>> Christophe >>> >>>> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >>>> >>>> Hi list, >>>> >>>> Well, subject says pretty much all. >>>> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >>>> Then, it will be a âdev-8.0â and so onâ¦ >>>> >>>> So, be prepared to submit your PRs to dev-7.0 instead development :) >>>> >>>> Cheers, >>>> Esteban

Nov. 28, 2018

Re: [Pharo-dev] Version control of Playground scripts

by Norbert Hartl

> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman <christopher.fuhrman(a)inria.fr>: > > Hello, > > In Pharo 6.1 I have got Iceberg working and love the interface to GitHub. Thanks to the Rmod folks for all the patient answers to my newbie questions. > > However, most of my development remains in playground scripts, and as far I understand, it's not possible to put them under version control with Iceberg. > > My scripts *could* be turned into classes eventually (some already have been and are under Iceberg). But it feels frustrating to rush it, just to get the versioning. > > I know how to save Playground files to the web, which is useful, but of course not version control per se. > > Knowing Playground files are saved on local disk, I got to thinking... What would be the risk(s) of using git outside Pharo, on the Playground files' directory? Has anyone tried that before? > It is not a problem. I use this every day. Meaning all my repos have a scripts folder where I put my helper scripts. In the image I open this with âscriptsâ asFileReference inspect so you get kind of a file browser of all the scripts. If you call the files with an extension of .st you get syntax highlighting. If you change a script with cmd-s the file gets modified and you can check into git. The problem here is that if you have modifications in the image you should commit that first because if you do on the scripts folder first the image working copy is detached and there is no easy way to commit your in-image changes. You would have to do a branch which is cumbersome. With the scripts in place I have developed a workflow of creating new images. I have a script that downloads a new image and renames it for the project. And if it finds a script scripts/prepare-image.st <http://prepare-image.st/> it gets executed. This contains metacello commands to load the project code and settings I need in a new image. This way it is super easy to create a new image for your work. And as all the scripts you use are on the filesystem there is usually no state in the image that needs to be transferred to a new image. Norbert

Nov. 28, 2018

Re: [Pharo-dev] Version control of Playground scripts

by Esteban Lorenzano

Hi, > On 28 Nov 2018, at 09:38, Christopher Fuhrman <christopher.fuhrman(a)inria.fr> wrote: > > Hello, > > In Pharo 6.1 I have got Iceberg working and love the interface to GitHub. Thanks to the Rmod folks for all the patient answers to my newbie questions. > > However, most of my development remains in playground scripts, and as far I understand, it's not possible to put them under version control with Iceberg. > > My scripts *could* be turned into classes eventually (some already have been and are under Iceberg). But it feels frustrating to rush it, just to get the versioning. > > I know how to save Playground files to the web, which is useful, but of course not version control per se. > > Knowing Playground files are saved on local disk, I got to thinking... What would be the risk(s) of using git outside Pharo, on the Playground files' directory? Has anyone tried that before? It should be possible without any risk. You should: a) Redirect playground cache to some place you want (option is somewhere in settingsâ¦) b) Version those from outside. And the only drawback is that you will need to ârepairâ your image project each time you do that, because the project will move to âdetached stateâ. But repair is easy: just merge with your branch (99% of the time it will do a fast forward). Esteban > > Cheers, > > Christopher >

Nov. 28, 2018

Version control of Playground scripts

by Christopher Fuhrman

Hello, In Pharo 6.1 I have got Iceberg working and love the interface to GitHub. Thanks to the Rmod folks for all the patient answers to my newbie questions. However, most of my development remains in playground scripts, and as far I understand, it's not possible to put them under version control with Iceberg. My scripts *could* be turned into classes eventually (some already have been and are under Iceberg). But it feels frustrating to rush it, just to get the versioning. I know how to save Playground files to the web, which is useful, but of course not version control per se. Knowing Playground files are saved on local disk, I got to thinking... What would be the risk(s) of using git outside Pharo, on the Playground files' directory? Has anyone tried that before? Cheers, Christopher

Nov. 28, 2018

[Pharo 7.0-dev] Build #1418: 22700-add-value-and-operation-for-Blocks

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1418 was: SUCCESS. The Pull Request #2017 was integrated: "22700-add-value-and-operation-for-Blocks" Pull request url: https://github.com/pharo-project/pharo/pull/2017 Issue Url: https://pharo.fogbugz.com/f/cases/22700 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2018

[Pharo 7.0-dev] Build #1417: 22697-remove-oldvalue-reification

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1417 was: FAILURE. The Pull Request #2014 was integrated: "22697-remove-oldvalue-reification" Pull request url: https://github.com/pharo-project/pharo/pull/2014 Issue Url: https://pharo.fogbugz.com/f/cases/22697 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2018

[Pharo 7.0-dev] Build #1416: 22640-Sending-links-to-an-AST-should-not-return-nil-if-there-is-no-link

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1416 was: FAILURE. The Pull Request #2013 was integrated: "22640-Sending-links-to-an-AST-should-not-return-nil-if-there-is-no-link" Pull request url: https://github.com/pharo-project/pharo/pull/2013 Issue Url: https://pharo.fogbugz.com/f/cases/22640 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2018

[Pharo 7.0-dev] Build #1415: 22695-Make-value-for-work-method-after

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1415 was: FAILURE. The Pull Request #2012 was integrated: "22695-Make-value-for-work-method-after" Pull request url: https://github.com/pharo-project/pharo/pull/2012 Issue Url: https://pharo.fogbugz.com/f/cases/22695 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2018