On 10/14/2015 01:00 AM, Christophe Demarey wrote:
Le 12 oct. 2015 à 19:53, Dale Henrichs a écrit :
On 10/12/2015 02:58 AM, Christophe Demarey wrote:
Le 11 oct. 2015 à 22:32, Dale Henrichs a écrit :
When you talk about "virtual packages", I would say that a
BaselineOf is pretty much a "
On 10/14/2015 12:48 AM, Christophe Demarey wrote:
Le 12 oct. 2015 à 21:17, Dale Henrichs a écrit :
On 10/12/2015 02:58 AM, Christophe Demarey wrote:
Le 11 oct. 2015 à 22:32, Dale Henrichs a écrit :
With our approach, metadata lies in the package for the current version and it
is on the pa
On 10/14/2015 12:39 AM, Christophe Demarey wrote:
Le 12 oct. 2015 à 19:22, Dale Henrichs a écrit :
On 10/12/2015 02:20 AM, Christophe Demarey wrote:
Le 11 oct. 2015 à 18:42, Dale Henrichs a écrit :
On 10/11/15 12:19 AM, stepharo wrote:
Le 11/10/15 00:40, Dale Henrichs a écrit :
Christop
On 10/14/2015 12:15 AM, Christophe Demarey wrote:
Le 12 oct. 2015 à 19:01, Dale Henrichs a écrit :
On 10/12/2015 01:42 AM, Christophe Demarey wrote:
Hi Dale,
Le 11 oct. 2015 à 00:40, Dale Henrichs a écrit :
Christophe,
I still don't have a lot of time to read the paper and try to
und
On 14-10-15 08:25, Christophe Demarey wrote:
What does releasing mean here? Could you frame it in terms of the
5D paper and the problems they describe?
Regarding the 5D paper, what I call release is the version dimension,
where you edit design information. "the designers typically work on a
non
Le 12 oct. 2015 à 19:53, Dale Henrichs a écrit :
>
>
> On 10/12/2015 02:58 AM, Christophe Demarey wrote:
>>
>> Le 11 oct. 2015 à 22:32, Dale Henrichs a écrit :
>>
>>> When you talk about "virtual packages", I would say that a BaselineOf is
>>> pretty much a "virtual package" already.
>>
>>
Le 12 oct. 2015 à 21:17, Dale Henrichs a écrit :
>
>
> On 10/12/2015 02:58 AM, Christophe Demarey wrote:
>>
>> Le 11 oct. 2015 à 22:32, Dale Henrichs a écrit :
>>
>> With our approach, metadata lies in the package for the current version and
>> it is on the package repository when the versio
Le 12 oct. 2015 à 19:22, Dale Henrichs a écrit :
>
>
> On 10/12/2015 02:20 AM, Christophe Demarey wrote:
>> Le 11 oct. 2015 à 18:42, Dale Henrichs a écrit :
>>
>>>
>>> On 10/11/15 12:19 AM, stepharo wrote:
Le 11/10/15 00:40, Dale Henrichs a écrit :
> Christophe,
>
> I
Le 12 oct. 2015 à 19:01, Dale Henrichs a écrit :
>
>
> On 10/12/2015 01:42 AM, Christophe Demarey wrote:
>> Hi Dale,
>>
>> Le 11 oct. 2015 à 00:40, Dale Henrichs a écrit :
>>
>>> Christophe,
>>>
>>> I still don't have a lot of time to read the paper and try to understand
>>> what you are tr
Le 12 oct. 2015 à 14:03, Thierry Goubier a écrit :
>
> 2015-10-12 11:20 GMT+02:00 Christophe Demarey :
>
> Well, the point is not to replace metacello but to go towards a per package
> metadata description allowing some flexibility with the introduction of
> virtual packages.
> This will allo
Le 12 oct. 2015 à 12:53, Stephan Eggermont a écrit :
> On 12-10-15 10:42, Christophe Demarey wrote:
>
>> When you develop, you have a working copy of a package meta-data, including
>> dependencies. Actually, there are current dependencies of the package. You
>> could avoid to refer to specific
On 10/12/2015 02:58 AM, Christophe Demarey wrote:
Le 11 oct. 2015 à 22:32, Dale Henrichs a écrit :
With our approach, metadata lies in the package for the current
version and it is on the package repository when the version is
released. Platform-specific packages could have their own depend
On 10/12/2015 02:58 AM, Christophe Demarey wrote:
Le 11 oct. 2015 à 22:32, Dale Henrichs a écrit :
When you talk about "virtual packages", I would say that a BaselineOf
is pretty much a "virtual package" already.
I don't think BaselineOf could be seen as a virtual package.
In package A, yo
On 10/12/2015 02:20 AM, Christophe Demarey wrote:
Le 11 oct. 2015 à 18:42, Dale Henrichs a écrit :
On 10/11/15 12:19 AM, stepharo wrote:
Le 11/10/15 00:40, Dale Henrichs a écrit :
Christophe,
I still don't have a lot of time to read the paper and try to understand what
you are trying to
On 10/12/2015 01:42 AM, Christophe Demarey wrote:
Hi Dale,
Le 11 oct. 2015 à 00:40, Dale Henrichs a écrit :
Christophe,
I still don't have a lot of time to read the paper and try to
understand what you are trying to accomplish, but I am curious how
you think "package dependencies" will pl
On 10/11/2015 11:10 PM, stepharo wrote:
A BaselineOf has a single baseline method and only the "pure"
dependencies amongst the packages and projects needs to be expressed
... and these dependency specs are about "as small" as you can get ...
Yes but we want them per package.
We do not w
2015-10-12 11:20 GMT+02:00 Christophe Demarey :
>
> Well, the point is not to replace metacello but to go towards a per
> package metadata description allowing some flexibility with the
> introduction of virtual packages.
> This will allow, in a first time, to set up a package repository and more
On 12-10-15 10:42, Christophe Demarey wrote:
When you develop, you have a working copy of a package meta-data, including
dependencies. Actually, there are current dependencies of the package. You
could avoid to refer to specific versions and just point to the package name as
your working imag
Le 11 oct. 2015 à 22:32, Dale Henrichs a écrit :
> When you talk about "virtual packages", I would say that a BaselineOf is
> pretty much a "virtual package" already.
I don't think BaselineOf could be seen as a virtual package.
In package A, you tell that A depends on V.
In package B, you simpl
Le 11 oct. 2015 à 18:42, Dale Henrichs a écrit :
>
>
> On 10/11/15 12:19 AM, stepharo wrote:
>>
>>
>> Le 11/10/15 00:40, Dale Henrichs a écrit :
>>> Christophe,
>>>
>>> I still don't have a lot of time to read the paper and try to understand
>>> what you are trying to accomplish,
>> you sh
Hi Dale,
Le 11 oct. 2015 à 00:40, Dale Henrichs a écrit :
> Christophe,
>
> I still don't have a lot of time to read the paper and try to understand what
> you are trying to accomplish, but I am curious how you think "package
> dependencies" will play with git-based projects?
Dependencies are
A BaselineOf has a single baseline method and only the "pure"
dependencies amongst the packages and projects needs to be expressed
... and these dependency specs are about "as small" as you can get ...
Yes but we want them per package.
We do not work on that since more than one year by acc
On 10/11/15 11:40 AM, stepharo wrote:
I think that this is only true for packages committed within the
same repo.
Now between porjects published in different repo you have to express
them.
I do not think that we all want to publish in the same repo and
clone out everything.
... and inter-
I think that this is only true for packages committed within the same
repo.
Now between porjects published in different repo you have to express
them.
I do not think that we all want to publish in the same repo and clone
out everything.
... and inter-project dependencies is what a BaselineOf
On 10/11/15 12:19 AM, stepharo wrote:
Le 11/10/15 00:40, Dale Henrichs a écrit :
Christophe,
I still don't have a lot of time to read the paper and try to
understand what you are trying to accomplish,
you should read it. :)
We wrote it for that and it is not boring nor long.
I scanned th
Le 11/10/15 00:40, Dale Henrichs a écrit :
Christophe,
I still don't have a lot of time to read the paper and try to
understand what you are trying to accomplish,
you should read it. :)
We wrote it for that and it is not boring nor long.
but I am curious how you think "package dependencies
Christophe,
I still don't have a lot of time to read the paper and try to understand
what you are trying to accomplish, but I am curious how you think
"package dependencies" will play with git-based projects?
In git-based repositories I don't think you have the same type of
dependency issues
Hi Stephan,
Le 7 oct. 2015 à 10:22, Stephan Eggermont a écrit :
> On 07/10/15 08:47, Christophe Demarey wrote:
>> If you have any question or remark, do not hesitate to ask or to give
>> feedback.
>
> How do you express the migration of functionality from one package to
> another? How does tha
On 07/10/15 08:47, Christophe Demarey wrote:
If you have any question or remark, do not hesitate to ask or to give feedback.
How do you express the migration of functionality from one package to
another? How does that affect users of those packages?
How do you intend to deal with variants (as
Hi Dale,
Le 6 oct. 2015 à 20:23, Dale Henrichs a écrit :
>
>
> On 10/6/15 5:10 AM, stepharo wrote:
>>
>>
>> Le 6/10/15 11:40, Stephan Eggermont a écrit :
>>> On 06-10-15 11:11, stepharo wrote:
I will do a separate configuration of magritte seaside.
>>>
>>> You need to load the correct g
On 10/6/15 11:43 AM, stepharo wrote:
Stef,
I hope you and Christophe are considering cross platform
considerations when implementing "new dependencies declarations at
the package level" ... MonticelloConfigurations had "package level
dependencies" and the implementation was extremely rigi
Stef,
I hope you and Christophe are considering cross platform
considerations when implementing "new dependencies declarations at the
package level" ... MonticelloConfigurations had "package level
dependencies" and the implementation was extremely rigid to the point
where it wasn't possible
On 10/6/15 5:10 AM, stepharo wrote:
Le 6/10/15 11:40, Stephan Eggermont a écrit :
On 06-10-15 11:11, stepharo wrote:
I will do a separate configuration of magritte seaside.
You need to load the correct groups. Separate configurations are a
bad practice and should be eliminated, not encou
The many configurations of GT/Glamour have not exactly convinced me.
For a configuration that works when just loading #'stable' from the
configuration browser, I'd suggest trying with the configuration of
BootstrapMagritte. That only runs into the #subStrings: vs #substrings:.
Stephan
Le 6/10/15 11:40, Stephan Eggermont a écrit :
On 06-10-15 11:11, stepharo wrote:
I will do a separate configuration of magritte seaside.
You need to load the correct groups. Separate configurations are a bad
practice and should be eliminated, not encouraged.
I totally disagree.
And groups
On 06-10-15 11:11, stepharo wrote:
I will do a separate configuration of magritte seaside.
You need to load the correct groups. Separate configurations are a bad
practice and should be eliminated, not encouraged. The configuration has
a lot of essential complexity, as many different combinati
> On Oct 6, 2015, at 11:11 AM, stepharo wrote:
>
> Hi guys
>
> How can I get Magritte seaside (and a working version not one breaking on XML
> I do not what)?
> I loaded the published stable version of Magritte into Pharo and there is no
> seaside version.
> I checked the configuration and it
Hi guys
How can I get Magritte seaside (and a working version not one breaking
on XML I do not what)?
I loaded the published stable version of Magritte into Pharo and there
is no seaside version.
I checked the configuration and it is so complex
I have the impression that we need to distin
38 matches
Mail list logo
