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

2018-03-25 Thread stephan
On 20-03-18 08:55, Stephan Eggermont wrote: Cyril Ferlicot D. wrote: Le 19/03/2018 à 18:49, Stephan Eggermont a écrit : Then why bother releasing? Hi, For people using Pharo 7 to not get the same bugs for more than 1 year, to get the new functionalities and to be

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

2018-03-20 Thread Stephan Eggermont
Cyril Ferlicot D. wrote: > Le 19/03/2018 à 18:49, Stephan Eggermont a écrit : >> Then why bother releasing? >> > > Hi, > > For people using Pharo 7 to not get the same bugs for more than 1 year, > to get the new functionalities and to be able to detect new bugs >

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

2018-03-19 Thread Cyril Ferlicot D.
Le 19/03/2018 à 18:49, Stephan Eggermont a écrit : > Then why bother releasing? > Hi, For people using Pharo 7 to not get the same bugs for more than 1 year, to get the new functionalities and to be able to detect new bugs introduced in releases. > Stephan > > > > > -- Cyril Ferlicot

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

2018-03-19 Thread Stephan Eggermont
Denis Kudriashov wrote: > 2018-03-19 9:16 GMT+01:00 Stephan Eggermont : > >> Denis Kudriashov >> wrote: >>> 2018-03-17 17:01 GMT+01:00 Stephan Eggermont >> : >>> Denis Kudriashov

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

2018-03-19 Thread Denis Kudriashov
2018-03-19 9:16 GMT+01:00 Stephan Eggermont : > Denis Kudriashov > wrote: > > 2018-03-17 17:01 GMT+01:00 Stephan Eggermont > : > > > >> Denis Kudriashov > >> wrote: > >>> > >>> No. Each build just loads specified

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

2018-03-19 Thread Stephan Eggermont
Denis Kudriashov wrote: > 2018-03-17 17:01 GMT+01:00 Stephan Eggermont : > >> Denis Kudriashov >> wrote: >>> >>> No. Each build just loads specified version. I do not need to create new >>> version for new build. >>> But I think I

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

2018-03-18 Thread Denis Kudriashov
2018-03-17 17:01 GMT+01:00 Stephan Eggermont : > Denis Kudriashov > wrote: > > > > No. Each build just loads specified version. I do not need to create new > > version for new build. > > But I think I still not understand you > > That specified version

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

2018-03-17 Thread Stephan Eggermont
Denis Kudriashov wrote: > > No. Each build just loads specified version. I do not need to create new > version for new build. > But I think I still not understand you That specified version will no longer work in a newer pharo build. Pharo changes, making it necessary for

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

2018-03-17 Thread Denis Kudriashov
2018-03-17 13:29 GMT+01:00 Stephan Eggermont : > Denis Kudriashov > wrote: > > 2018-03-17 13:15 GMT+01:00 Stephan Eggermont > : > > > >> Denis Kudriashov > >> wrote: > >> > >>> So to get all minor fixes from all

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

2018-03-17 Thread Stephan Eggermont
Denis Kudriashov wrote: > 2018-03-17 13:15 GMT+01:00 Stephan Eggermont : > >> Denis Kudriashov >> wrote: >> >>> So to get all minor fixes from all dependencies the code should be loaded >>> from such floating branch (0.5.x). The

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

2018-03-17 Thread Denis Kudriashov
2018-03-17 13:15 GMT+01:00 Stephan Eggermont : > Denis Kudriashov > wrote: > > > So to get all minor fixes from all dependencies the code should be loaded > > from such floating branch (0.5.x). The main project can be locked to fix > > current version

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

2018-03-17 Thread Stephan Eggermont
Denis Kudriashov wrote: > So to get all minor fixes from all dependencies the code should be loaded > from such floating branch (0.5.x). The main project can be locked to fix > current version (only dependencies will be updated). > And all released versions (0.5.3 tag) will

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

2018-03-16 Thread Thierry Goubier
Le 16/03/2018 à 18:37, Denis Kudriashov a écrit : 2018-03-05 16:17 GMT+01:00 Denis Kudriashov >: 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot >: On Mon, Mar 5, 2018 at

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

2018-03-16 Thread Denis Kudriashov
2018-03-05 16:17 GMT+01:00 Denis Kudriashov : > 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot : > >> On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov >> wrote: >> > Hi Pablo. >> > >> > Dev branch approach not really works. Because

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

2018-03-07 Thread Stephane Ducasse
Thanks dale I will watch and read and sync with guys when I'm back to civilisation :) On Tue, Mar 6, 2018 at 6:35 PM, Dale Henrichs < dale.henri...@gemtalksystems.com> wrote: > > > On 03/06/2018 06:21 AM, Guillermo Polito wrote: > > Hi Dale! > > On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs < >

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

2018-03-07 Thread Ben Coman
On 5 March 2018 at 23:51, Guillermo Polito wrote: > > > On Mon, Mar 5, 2018 at 4:45 PM, Cyril Ferlicot > wrote: > >> >> On Mon, Mar 5, 2018 at 4:38 PM, Guillermo Polito < >> guillermopol...@gmail.com> wrote: >> >>> But, "one single class"

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

2018-03-06 Thread Dale Henrichs
On 03/06/2018 06:21 AM, Guillermo Polito wrote: Hi Dale! On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs > wrote: On 03/05/2018 09:07 AM, Guillermo Polito wrote: On the other side, there is the fact

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

2018-03-06 Thread Denis Kudriashov
So I made pull request for new Calypso version. It modifies #loadCalypso method to fix versions of all dependencies using locking statements. I checked it for Pharo 6. It works fine. https://github.com/pharo-project/pharo/pull/1037 2018-03-05 20:25 GMT+01:00 Dale Henrichs

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

2018-03-06 Thread Guillermo Polito
Hi Dale! On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs < dale.henri...@gemtalksystems.com> wrote: > > > On 03/05/2018 09:07 AM, Guillermo Polito wrote: > >> On the other side, there is the fact that Metacello baselines are so far >> nice to describe release project dependencies, but they are not

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

2018-03-05 Thread Dale Henrichs
On 03/05/2018 11:22 AM, Stephane Ducasse wrote: In an image where you want to use the dev_pharo7 for a project, you do a Metacello lock on github:///xxx:dev_pharo7/src BEFORE loading the project ... if there are multiple projects that need to all coordinate development then you follow the

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

2018-03-05 Thread Stephane Ducasse
On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs wrote: > > > On 03/05/2018 09:07 AM, Guillermo Polito wrote: >> >> On the other side, there is the fact that Metacello baselines are so far >> nice to describe release project dependencies, but they are not so nice to

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

2018-03-05 Thread Dale Henrichs
That's fine ... but then it should be a separate thread ... Dale On 03/05/2018 11:16 AM, Stephane Ducasse wrote: Dale no private emails please. stef On Mon, Mar 5, 2018 at 6:57 PM, Dale Henrichs wrote: Cyril, For development I tend to use Metacello

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

2018-03-05 Thread Dale Henrichs
Denis, See the "Lock Command Reference"[1] .. As I mention in a subsequent message I think that the best approach is to have meta specification for the configuration of a development environment that includes a spec for what should be loaded and this spec needs to be something that

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

2018-03-05 Thread Stephane Ducasse
Dale no private emails please. stef On Mon, Mar 5, 2018 at 6:57 PM, Dale Henrichs wrote: > Cyril, > > For development I tend to use Metacello locking instead of hard-wired > dependencies in the BaselineOf and that works very well --- it completely > avoids the

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

2018-03-05 Thread Dale Henrichs
On 03/05/2018 09:07 AM, Guillermo Polito wrote: On the other side, there is the fact that Metacello baselines are so far nice to describe release project dependencies, but they are not so nice to describe subprojects/development dependencies that may get edited along with the parent project.

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

2018-03-05 Thread Denis Kudriashov
Hi Dale. Where to read about locking? 2018-03-05 18:57 GMT+01:00 Dale Henrichs : > Cyril, > > For development I tend to use Metacello locking instead of hard-wired > dependencies in the BaselineOf and that works very well --- it completely > avoids the need to

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

2018-03-05 Thread Dale Henrichs
On 03/05/2018 08:48 AM, Stephan Eggermont wrote: teso...@gmail.com wrote: 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? Because that is the way it

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

2018-03-05 Thread Stephan Eggermont
Denis Kudriashov wrote: > > It is clear that we need both baselines for that case. > But because we will move Calypso to Pharo repo I think it is easy to manage > strong versions directly in Pharo loading script for now (in #loadCalypso > method). Easy for now, yes. And

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

2018-03-05 Thread Dale Henrichs
Cyril, For development I tend to use Metacello locking instead of hard-wired dependencies in the BaselineOf and that works very well --- it completely avoids the need to edit a baseline for development purposes and this approach works really well for me ... perhaps we can discuss this in

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

2018-03-05 Thread Denis Kudriashov
2018-03-05 18:23 GMT+01:00 Stephan Eggermont : > Guillermo Polito > wrote: > >... > > > > So yes, it may block upgrades, but until we have tools that allow us to > > cope with the complexity, I prefer to have reproducible versions where I > > can

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

2018-03-05 Thread Nicolas Cellier
2018-03-05 18:23 GMT+01:00 Stephan Eggermont : > Guillermo Polito > wrote: > >... > > > > So yes, it may block upgrades, but until we have tools that allow us to > > cope with the complexity, I prefer to have reproducible versions where I > > can

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

2018-03-05 Thread Stephan Eggermont
Guillermo Polito wrote: >... > > So yes, it may block upgrades, but until we have tools that allow us to > cope with the complexity, I prefer to have reproducible versions where I > can reproduce bugs in a reproducible way than an unpredictable version > where I cannot

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

2018-03-05 Thread Stephane Ducasse
On Mon, Mar 5, 2018 at 6:07 PM, Guillermo Polito wrote: > Yes and no. I think I kind of get it now from all comments... There are > two problems together, one is how to reproduce the loading of a project (or > getting a working version), and the other is how to use

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

2018-03-05 Thread Guillermo Polito
Yes and no. I think I kind of get it now from all comments... There are two problems together, one is how to reproduce the loading of a project (or getting a working version), and the other is how to use metacello also to manage the development of the project when the dependencies feel more like

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

2018-03-05 Thread Nicolas Cellier
The well known problem with fixed configurations is dependencies: My project A version 1.2.3 depends on project C version 4.3 (semantic versioning). I have tested it with 4.3.35, it works well... If semantic versioning is correctly used, it should work with any 4.x.y where x>=3. There is another

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

2018-03-05 Thread Stephan Eggermont
teso...@gmail.com wrote: > 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? Because that is the way it should be? It is hand-edited, so repeatable builds

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

2018-03-05 Thread Denis Kudriashov
2018-03-05 17:02 GMT+01:00 Cyril Ferlicot : > > On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito < > guillermopol...@gmail.com> wrote: >> >> >> I still do not understand... Also I do not understand your usage of the >> term "the merge". Can somebody give a **concrete**

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

2018-03-05 Thread Pavel Krivanek
as far as I understand it, you have this: Calypso v1 - Commander v1 - ClassAnnotations v1 You are working on and you fix a version in ClassAnnotations Calypso v1 - Commander v1 - ClassAnnotations v2 but you still do not want to make it as a release. When rebuilding your image, you

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

2018-03-05 Thread Cyril Ferlicot
On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito wrote: > > > I still do not understand... Also I do not understand your usage of the > term "the merge". Can somebody give a **concrete** scenario? > > I'll try For example the project MaterialDesignLite have two branches

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

2018-03-05 Thread Guillermo Polito
But can you explain me the scenario? I still don't understand it :( On Mon, Mar 5, 2018 at 4:51 PM, Denis Kudriashov wrote: > Maybe we should just load Calypso dependencies explicitly. > In any case they will be used by other projects. Like new Iceberg will use >

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

2018-03-05 Thread Denis Kudriashov
Maybe we should just load Calypso dependencies explicitly. In any case they will be used by other projects. Like new Iceberg will use Commander. And ClassAnnotation will be in Kernel. So we will need to load them in another time than Calypso. Now we can just put them directly into #loadCalypso

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

2018-03-05 Thread Guillermo Polito
On Mon, Mar 5, 2018 at 4:45 PM, Cyril Ferlicot wrote: > > On Mon, Mar 5, 2018 at 4:38 PM, Guillermo Polito < > guillermopol...@gmail.com> wrote: > >> But, "one single class" does not mean anything. Because it depends from >> which branch/commitish you are loading it

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

2018-03-05 Thread Cyril Ferlicot
On Mon, Mar 5, 2018 at 4:38 PM, Guillermo Polito 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

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

2018-03-05 Thread 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 : > But, "one single class" does not mean anything.

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

2018-03-05 Thread 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

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

2018-03-05 Thread Denis Kudriashov
2018-03-05 16:13 GMT+01:00 Cyril Ferlicot : > On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov > wrote: > > Hi Pablo. > > > > Dev branch approach not really works. Because any merge into master will > > break master baseline. (notice that baseline

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

2018-03-05 Thread 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 teso...@gmail.com : > Yes, I understand for the developer version, you should have a developer >

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

2018-03-05 Thread Cyril Ferlicot
On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov 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. > >

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

2018-03-05 Thread 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 teso...@gmail.com : > Yes, I understand

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

2018-03-05 Thread teso...@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 wrote: > Hi, > > it is an issue of Calypso dependencies. I discussed it with Denis >

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

2018-03-05 Thread Pavel Krivanek
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