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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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 <
>
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"
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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**
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
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
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
>
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
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
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
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.
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
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
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
>
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.
>
>
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
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
>
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
51 matches
Mail list logo