Dale Henrichs wrote
> When Cami refers to "automatic dependencies" he's referring to the fact
> that with ruby-gems one can specify a range of versions that will satisfy
> the dependencies for your project instead of a single version as is done
> with Metacello today.
Yes, I want this and IIRC we'
On 22 Apr 2013, at 17:37, Dale Henrichs wrote:
> Now that folks like you are asking for features that I think I've addressed
> in the Scripting API, perhaps I can start getting some meaningful feedback.
> If your projects are on Pharo2.0, you'll have to wait for Christophe and I to
> finish th
ion.
Dale
[1] http://semver.org/
- Original Message -
| From: "Sean P. DeNigris"
| To: pharo-project@lists.gforge.inria.fr
| Sent: Friday, April 19, 2013 5:27:55 AM
| Subject: Re: [Pharo-project] Metacello configuration conventions
|
| > Metacello supports both
s well:)
Dale
[1] https://github.com/dalehenrich/metacello-work/blob/master/README.md
- Original Message -
| From: "Diego Lont"
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, April 19, 2013 1:36:37 AM
| Subject: Re: [Pharo-project] Metacello configuration conventions
|
l 18, 2013 12:57:47 PM
| Subject: Re: [Pharo-project] Metacello configuration conventions
|
|
| On 2013-04-18, at 18:47, Dale Henrichs wrote:
|
| >
| >
| > - Original Message -
| > | From: "Camillo Bruni"
| > | To: Pharo-project@lists.gforge.inria.fr
| > | Se
> Metacello supports both, but not at the same time. Either you mark your
> configuration with fixed versions (best for patches) or with symbolic
> versions (best for releases).
I don't understand this. If you don't want your dependencies upgraded, you
don't change the versions referenced in you
On 2013-04-19, at 11:04, Frank Shearar wrote:
> On 19 April 2013 09:55, Camillo Bruni wrote:
>>
>> On 2013-04-19, at 10:36, Diego Lont wrote:
>>
>>> Hi all,
>>>
>>> I just want to add another thought to the convention discussion.
>>>
>>> In my work process I have two different activities whe
On 19 April 2013 09:55, Camillo Bruni wrote:
>
> On 2013-04-19, at 10:36, Diego Lont wrote:
>
>> Hi all,
>>
>> I just want to add another thought to the convention discussion.
>>
>> In my work process I have two different activities when deploying new code:
>> 1) I want to deploy a patch, t
On 2013-04-19, at 10:36, Diego Lont wrote:
> Hi all,
>
> I just want to add another thought to the convention discussion.
>
> In my work process I have two different activities when deploying new code:
> 1) I want to deploy a patch, that only includes the bugfix.
> 2) I want to dep
Hi all,
I just want to add another thought to the convention discussion.
In my work process I have two different activities when deploying new code:
1) I want to deploy a patch, that only includes the bugfix.
2) I want to deploy a release, that includes all updates.
In the first
On 2013-04-18, at 18:47, Dale Henrichs wrote:
>
>
> - Original Message -
> | From: "Camillo Bruni"
> | To: Pharo-project@lists.gforge.inria.fr
> | Sent: Tuesday, April 16, 2013 3:19:57 PM
> | Subject: Re: [Pharo-project] Metacello configuration convent
>
>
> - Original Message -
> | From: "Camillo Bruni"
> | To: Pharo-project@lists.gforge.inria.fr
> | Sent: Tuesday, April 16, 2013 3:19:57 PM
> | Subject: Re: [Pharo-project] Metacello configuration conventions
> |
> | I liked ruby-gems approach more t
On 18 April 2013 17:47, Dale Henrichs wrote:
>
>
> - Original Message -
> | From: "Camillo Bruni"
> | To: Pharo-project@lists.gforge.inria.fr
> | Sent: Tuesday, April 16, 2013 3:19:57 PM
> | Subject: Re: [Pharo-project] Metacello configuration conven
Dale Henrichs wrote
> The Metacello Preview will support semantic versioning system!
Cool! Thanks Dale :)
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682362.html
Sent from the Pharo Smalltalk mailing list archive at N
- Original Message -
| From: "Camillo Bruni"
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Tuesday, April 16, 2013 3:19:57 PM
| Subject: Re: [Pharo-project] Metacello configuration conventions
|
| I liked ruby-gems approach more than the one in Metacello. You usually
| s
[Pharo-project] Metacello configuration conventions
|
| Camillo Bruni-3 wrote
| > I liked ruby-gems approach more than the one in Metacello. You usually
| > specify
| > a major version (as under linux) for your dependency.
|
| It seems they're using semantic versioning, which is *awesome
Yes. It would be very helpful to highlight a bit compatibility between versions.
I keep that in mind for versionner.
Le 17 avr. 2013 à 11:10, Camillo Bruni a écrit :
>
> On 2013-04-17, at 02:50, "Sean P. DeNigris" wrote:
>
>> Camillo Bruni-3 wrote
>>> I liked ruby-gems approach more than the o
On 2013-04-17, at 02:50, "Sean P. DeNigris" wrote:
> Camillo Bruni-3 wrote
>> I liked ruby-gems approach more than the one in Metacello. You usually
>> specify
>> a major version (as under linux) for your dependency.
>
> It seems they're using semantic versioning, which is *awesome*, but can we
Camillo Bruni-3 wrote
> I liked ruby-gems approach more than the one in Metacello. You usually
> specify
> a major version (as under linux) for your dependency.
It seems they're using semantic versioning, which is *awesome*, but can we
depend on the convention being followed? I've been pushing to
Christophe Demarey wrote
> As a general purpose reflexion on dependencies conventions, I would say:
> If you are in development mode, it makes sense to rely on latest versions
> of dependencies (bleeding edge) to be able to detect integration problems
> as soon as possible.
> If you are in a releas
On 2013-04-16, at 23:25, Frank Shearar wrote:
> On 16 April 2013 19:52, stephane ducasse wrote:
>> Christophe I agree with you
>>
>> As a general purpose reflexion on dependencies conventions, I would say:
>>
>> If you are in development mode, it makes sense to rely on latest versions of
>> d
On 16 April 2013 19:52, stephane ducasse wrote:
> Christophe I agree with you
>
> As a general purpose reflexion on dependencies conventions, I would say:
>
> If you are in development mode, it makes sense to rely on latest versions of
> dependencies (bleeding edge) to be able to detect integratio
Christophe I agree with you
> As a general purpose reflexion on dependencies conventions, I would say:
> If you are in development mode, it makes sense to rely on latest versions of
> dependencies (bleeding edge) to be able to detect integration problems as
> soon as possible.
> If you are in a
On 16 April 2013 15:11, Stephan Eggermont wrote:
> Frank wrote:
>>I'd argue that since you're declaring that a certain set of versions
>>of packages work together, you should _always_ use explicit versions.
>>The "optimistic" strategy leaves you vulnerable to third parties
>>making seemingly innoc
Frank wrote:
>I'd argue that since you're declaring that a certain set of versions
>of packages work together, you should _always_ use explicit versions.
>The "optimistic" strategy leaves you vulnerable to third parties
>making seemingly innocuous changes that break your code. (I've been
>bitten by
As a general purpose reflexion on dependencies conventions, I would say:
If you are in development mode, it makes sense to rely on latest versions of
dependencies (bleeding edge) to be able to detect integration problems as soon
as possible.
If you are in a release mode, you should ensure that yo
On 16 April 2013 09:53, Stephan Eggermont wrote:
> Hi,
>
> While working with Diego on some configurations, we noticed two different
> styles
> of describing the latest non-baseline versions.
>
> In one, the versionString version of a dependency is used.
> That is a defensive strategy, where you
Hi,
While working with Diego on some configurations, we noticed two different styles
of describing the latest non-baseline versions.
In one, the versionString version of a dependency is used.
That is a defensive strategy, where you want to specify the exact version that
will be loaded (and has b
28 matches
Mail list logo
