: Thursday, April 18, 2013 12:57:47 PM
| Subject: Re: [Pharo-project] Metacello configuration conventions
|
|
| On 2013-04-18, at 18:47, Dale Henrichs dhenr...@vmware.com wrote:
|
|
|
| - Original Message -
| | From: Camillo Bruni camillobr...@gmail.com
| | To: Pharo-project
/master/README.md
- Original Message -
| From: Diego Lont diego.l...@delware.nl
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, April 19, 2013 1:36:37 AM
| Subject: Re: [Pharo-project] Metacello configuration conventions
|
| Hi all,
|
| I just want to add another thought
/
- Original Message -
| From: Sean P. DeNigris s...@clipperadams.com
| 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, but not at the same time. Either you mark
On 22 Apr 2013, at 17:37, Dale Henrichs dhenr...@vmware.com 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
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've
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-19, at 10:36, Diego Lont diego.l...@delware.nl 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.
On 19 April 2013 09:55, Camillo Bruni camillobr...@gmail.com wrote:
On 2013-04-19, at 10:36, Diego Lont diego.l...@delware.nl 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:
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 your
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 s...@clipperadams.com wrote:
Camillo Bruni-3 wrote
I liked ruby-gems approach
: [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*, but can we
- Original Message -
| From: Camillo Bruni camillobr...@gmail.com
| 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
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
On 18 April 2013 17:47, Dale Henrichs dhenr...@vmware.com wrote:
- Original Message -
| From: Camillo Bruni camillobr...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Tuesday, April 16, 2013 3:19:57 PM
| Subject: Re: [Pharo-project] Metacello configuration conventions
- Original Message -
| From: Camillo Bruni camillobr...@gmail.com
| 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
On 2013-04-18, at 18:47, Dale Henrichs dhenr...@vmware.com wrote:
- Original Message -
| From: Camillo Bruni camillobr...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Tuesday, April 16, 2013 3:19:57 PM
| Subject: Re: [Pharo-project] Metacello configuration
On 2013-04-17, at 02:50, Sean P. DeNigris s...@clipperadams.com 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*,
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
On 16 April 2013 09:53, Stephan Eggermont step...@stack.nl 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,
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
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 this,
On 16 April 2013 15:11, Stephan Eggermont step...@stack.nl 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
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 19:52, stephane ducasse stephane.duca...@free.fr 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
On 2013-04-16, at 23:25, Frank Shearar frank.shea...@gmail.com wrote:
On 16 April 2013 19:52, stephane ducasse stephane.duca...@free.fr 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
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 release
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
27 matches
Mail list logo
