- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Guillermo Polito

On Mon, Mar 5, 2018 at 4:45 PM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Mon, Mar 5, 2018 at 4:38 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> But, "one single class" does not mean anything. Because it depends from >> which branch/commitish you are loading it from... >> >> Can you explain better what is the problem because I am not getting it... >> >> In any case, independently of where is the burden, I want to veto any new >> integration that may make future builds non-reproducible. Otherwise this is >> a source of chaos and dead kittens. >> >> The problem is that actually if you have a git project with a stable and > dev branch you will need: > - One baseline on the stable branch with determined dependencies versions > - One baseline on the dev branch with less restricted versions (for > example 3.x.x) > Then, when you release a new stable version by merging the development > branch you need to edit the merge by hand to merge everything except the > baseline. > I think this is what Denis wants to avoid. > But in general, such merges need to be done only for major and minor > releases. Not for a patch because you can do a hotfix. You create a new > branch from master, then merge in in master and development when it's done. > I still do not understand... Also I do not understand your usage of the term "the merge". Can somebody give a **concrete** scenario? When you release a version, please do not move that version. You should then create new versions, with new numbers and new code. But never touch old versions with old numbers and old code. Like that I can download the same old code using the same old number to get the old version whenever I want :). You can try to do it with branches, tags, different repositories, or even with zipfiles in mails. I don't care. Just don't modify releases and I'm happy with it. > > -- > Cyril Ferlicot > https://ferlicot.fr > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Cyril Ferlicot

On Mon, Mar 5, 2018 at 4:38 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > But, "one single class" does not mean anything. Because it depends from > which branch/commitish you are loading it from... > > Can you explain better what is the problem because I am not getting it... > > In any case, independently of where is the burden, I want to veto any new > integration that may make future builds non-reproducible. Otherwise this is > a source of chaos and dead kittens. > > The problem is that actually if you have a git project with a stable and dev branch you will need: - One baseline on the stable branch with determined dependencies versions - One baseline on the dev branch with less restricted versions (for example 3.x.x) Then, when you release a new stable version by merging the development branch you need to edit the merge by hand to merge everything except the baseline. I think this is what Denis wants to avoid. But in general, such merges need to be done only for major and minor releases. Not for a patch because you can do a hotfix. You create a new branch from master, then merge in in master and development when it's done. -- Cyril Ferlicot https://ferlicot.fr

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

In Configuration I defined two baselines: dev and stable. In dev baseline I referenced dev version of dependencies. In stable I referenced stable version of dependencies. 2018-03-05 16:38 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > But, "one single class" does not mean anything. Because it depends from > which branch/commitish you are loading it from... > > Can you explain better what is the problem because I am not getting it... > > In any case, independently of where is the burden, I want to veto any new > integration that may make future builds non-reproducible. Otherwise this is > a source of chaos and dead kittens. > > On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: >> >>> On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> > Hi Pablo. >>> > >>> > Dev branch approach not really works. Because any merge into master >>> will >>> > break master baseline. (notice that baseline is in same repo). >>> > And managing merges by hand all the time is not a solution. >>> > >>> > >>> Hi! >>> If you don't want to manage the merges by hand you can maybe have two >>> bsaelines? >>> BaselineOfCalypso and BaselineOfCalypsoDev? >>> >> >> It should work. But is it right way that everybody should follow? >> >> With configurations it was easy to do in single class. >> >> >>> >>> -- >>> Cyril Ferlicot >>> https://ferlicot.fr >>> >>> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Guillermo Polito

But, "one single class" does not mean anything. Because it depends from which branch/commitish you are loading it from... Can you explain better what is the problem because I am not getting it... In any case, independently of where is the burden, I want to veto any new integration that may make future builds non-reproducible. Otherwise this is a source of chaos and dead kittens. On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > >> On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > Hi Pablo. >> > >> > Dev branch approach not really works. Because any merge into master will >> > break master baseline. (notice that baseline is in same repo). >> > And managing merges by hand all the time is not a solution. >> > >> > >> Hi! >> If you don't want to manage the merges by hand you can maybe have two >> bsaelines? >> BaselineOfCalypso and BaselineOfCalypsoDev? >> > > It should work. But is it right way that everybody should follow? > > With configurations it was easy to do in single class. > > >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > Hi Pablo. > > > > Dev branch approach not really works. Because any merge into master will > > break master baseline. (notice that baseline is in same repo). > > And managing merges by hand all the time is not a solution. > > > > > Hi! > If you don't want to manage the merges by hand you can maybe have two > bsaelines? > BaselineOfCalypso and BaselineOfCalypsoDev? > It should work. But is it right way that everybody should follow? With configurations it was easy to do in single class. > > -- > Cyril Ferlicot > https://ferlicot.fr > >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

Also it is not really development versions. I follow semantics versioning. So I reference 0.3.x versions to get all minor fixes from dependencies. 2018-03-05 15:57 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > Yes, I understand for the developer version, you should have a developer > branch and use that. The problem is for the Pharo image only. > > On Mon, Mar 5, 2018 at 3:39 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> Hi, >> >> it is an issue of Calypso dependencies. I discussed it with Denis >> before Calypso integration and he would like to change it but, for >> now, it would make the development for him much harder because he >> needs a way how to load the latest bleeding edge versions of the >> packages and no one was able to tell him the proper way how to support >> both scenarios (loading of a specific release and loading of the >> development versions) with baselines without needing of duplicate >> them. >> >> Anyway, I agree that the current state must be fixed as soon as possible. >> >> Cheers, >> -- Pavel >> >> 2018-03-05 15:30 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: >> > Hello, >> > i have seen in the latest version of Pharo baselines pointing to >> > "floating" versions. A version that is not fixed. I want to know why >> this is >> > like that? >> > >> > To me this is basically wrong, because basically this goes against the >> idea >> > of having repeatable builds. Also using semantic versions with tags in >> Git >> > is wrong, as tags should be immutable (that is why you have to use >> --force >> > to update them, in Guille's words "If you have to force it, it is not >> > good"). >> > >> > Cheers, >> > >> > -- >> > Pablo Tesone. >> > tesonep(a)gmail.com >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Cyril Ferlicot

On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Pablo. > > Dev branch approach not really works. Because any merge into master will > break master baseline. (notice that baseline is in same repo). > And managing merges by hand all the time is not a solution. > > Hi! If you don't want to manage the merges by hand you can maybe have two bsaelines? BaselineOfCalypso and BaselineOfCalypsoDev? -- Cyril Ferlicot https://ferlicot.fr

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

Hi Pablo. Dev branch approach not really works. Because any merge into master will break master baseline. (notice that baseline is in same repo). And managing merges by hand all the time is not a solution. 2018-03-05 15:57 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > Yes, I understand for the developer version, you should have a developer > branch and use that. The problem is for the Pharo image only. > > On Mon, Mar 5, 2018 at 3:39 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> Hi, >> >> it is an issue of Calypso dependencies. I discussed it with Denis >> before Calypso integration and he would like to change it but, for >> now, it would make the development for him much harder because he >> needs a way how to load the latest bleeding edge versions of the >> packages and no one was able to tell him the proper way how to support >> both scenarios (loading of a specific release and loading of the >> development versions) with baselines without needing of duplicate >> them. >> >> Anyway, I agree that the current state must be fixed as soon as possible. >> >> Cheers, >> -- Pavel >> >> 2018-03-05 15:30 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: >> > Hello, >> > i have seen in the latest version of Pharo baselines pointing to >> > "floating" versions. A version that is not fixed. I want to know why >> this is >> > like that? >> > >> > To me this is basically wrong, because basically this goes against the >> idea >> > of having repeatable builds. Also using semantic versions with tags in >> Git >> > is wrong, as tags should be immutable (that is why you have to use >> --force >> > to update them, in Guille's words "If you have to force it, it is not >> > good"). >> > >> > Cheers, >> > >> > -- >> > Pablo Tesone. >> > tesonep(a)gmail.com >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com >

March 5, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #652: 21490 Lint cleanup DirectoryEntryTest

by Marcus Denker

> On 5 Mar 2018, at 16:03, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #652 was: FAILURE. > > The Pull Request #1023 was integrated: "21490 Lint cleanup DirectoryEntryTest" > Pull request url: https://github.com/pharo-project/pharo/pull/1023 > > Issue Url: https://pharo.fogbugz.com/f/cases/21490 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… now the ci job and the build fails due to this: Downloading the latest pharoVM: http://files.pharo.org/get-files/70/pharo-linux-stable.zip unzip: cannot find or open pharo-vm/vm.zip, pharo-vm/vm.zip.zip or pharo-vm/vm.zip.ZIP. maybe the disk is full? Marcus

March 5, 2018

[Pharo 7.0-dev] Build #652: 21490 Lint cleanup DirectoryEntryTest

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

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

March 5, 2018