Smalltalk › Pharo › Pharo Smalltalk Developers

Metacello configuration conventions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

28 messages Options

Stephan Eggermont-3

Metacello configuration conventions

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 been tested).

In the other the #stable version is used. That is an optimistic strategy.
This is much less brittle (but might suddenly not work anymore).

Seaside uses defensive/mixed, while Magritte uses optimistic

Based on what criteria should I choose which one to use (in a Pharo context)?

Stephan & Diego

Frank Shearar-3

Re: Metacello configuration conventions

On 16 April 2013 09:53, Stephan Eggermont <[hidden email]> 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 want to specify the exact version that
> will be loaded (and has been tested).
>
> In the other the #stable version is used. That is an optimistic strategy.
> This is much less brittle (but might suddenly not work anymore).
>
> Seaside uses defensive/mixed, while Magritte uses optimistic
>
> Based on what criteria should I choose which one to use (in a Pharo context)?

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, by making such an apparently innocuous change.)

frank

> Stephan & Diego

demarey

Re: Metacello configuration conventions

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 your code can run at least on fixed dependencies versions (at the best, specify a range of versions you can use with possibly no upper limit if your dependencies ensure backward compatibility). You need reproducible loading of your tool/lib.

in my opinion, you shouldn't use #stable for release version as the only thing it ensure (if well tested) is that you will not have a broken version of the dependency. The stable version of your dependency will evolve and then the configuration of your release too. At a time, your version will not be usable at all because of that.
so I would specify a dependency with a versionString for release versions of your lib/tool. It ensures a minimum version.

Regards,

Christophe.

Le 16 avr. 2013 à 11:02, Frank Shearar a écrit :

On 16 April 2013 09:53, Stephan Eggermont <[hidden email]> 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 want to specify the exact version that
will be loaded (and has been tested).

In the other the #stable version is used. That is an optimistic strategy.
This is much less brittle (but might suddenly not work anymore).

Seaside uses defensive/mixed, while Magritte uses optimistic

Based on what criteria should I choose which one to use (in a Pharo context)?

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, by making such an apparently innocuous change.)

frank

Stephan & Diego

smime.p7s (5K) Download Attachment

Stephan Eggermont-3

Re: Metacello configuration conventions

In reply to this post by Stephan Eggermont-3

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, by making such an apparently innocuous change.)

Thank you. That's a clear vulnerability of the optimistic strategy.

That sounds nice, but also means getting a change rate that is the sum
of that of all your dependencies. It is also not very nice when you are
depending on things that have known bugs you know will be fixed soon.

What does it mean that a certain set of versions work together?
Implicit seems the assumption that #Pharo2x is #stable, and we don't talk
about the vm version or even worse the non-smalltalk dependencies.

I don't see Metacello descriptions specifying all loaded packages.

Stephan

Frank Shearar-3

Re: Metacello configuration conventions

On 16 April 2013 15:11, Stephan Eggermont <[hidden email]> 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 innocuous changes that break your code. (I've been
>>bitten by this, by making such an apparently innocuous change.)
>
> Thank you. That's a clear vulnerability of the optimistic strategy.
>
> That sounds nice, but also means getting a change rate that is the sum
> of that of all your dependencies. It is also not very nice when you are
> depending on things that have known bugs you know will be fixed soon.

Why? If you use a baseline during development, you don't specify your
own versions at all. It's only when you're preparing a release that
you need to harden up the dependencies. Or: I'd be very surprised to
see you needing to constantly update your _external_ dependencies.

> What does it mean that a certain set of versions work together?
> Implicit seems the assumption that #Pharo2x is #stable, and we don't talk
> about the vm version or even worse the non-smalltalk dependencies.
>
> I don't see Metacello descriptions specifying all loaded packages.

Indeed: as far as Metacello's concerned there's just #pharo20 or
#squeak or whatever. But then, _usually_ you won't need to do special
things for, say, Pharo 2.0 prior to some update N versus Pharo 2.0
from update N+1 onwards. (Where "2.0" is a stand-in for any
not-bleeding-edge version.)

frank

> Stephan
>

stephane ducasse

Re: Metacello configuration conventions

In reply to this post by demarey

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 release mode, you should ensure that your code can run at least on fixed dependencies versions (at the best, specify a range of versions you can use with possibly no upper limit if your dependencies ensure backward compatibility). You need reproducible loading of your tool/lib.
in my opinion, you shouldn't use #stable for release version as the only thing it ensure (if well tested) is that you will not have a broken version of the dependency. The stable version of your dependency will evolve and then the configuration of your release too. At a time, your version will not be usable at all because of that.

Because even if you milestone against a major version,

what you mean is that the package may change (and still work on 20 for example, but be incompatible with your software).

I will write something in the metacello chapter and see what I wrote on symbolic version.

so I would specify a dependency with a versionString for release versions of your lib/tool. It ensures a minimum version.

So I wonder when we should use stable.

Versionner will solve all these points for us :)

Stef

Regards,
Christophe.

Le 16 avr. 2013 à 11:02, Frank Shearar a écrit :

On 16 April 2013 09:53, Stephan Eggermont <[hidden email]> 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 want to specify the exact version that
will be loaded (and has been tested).

In the other the #stable version is used. That is an optimistic strategy.
This is much less brittle (but might suddenly not work anymore).

Seaside uses defensive/mixed, while Magritte uses optimistic

Based on what criteria should I choose which one to use (in a Pharo context)?

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, by making such an apparently innocuous change.)

frank

Stephan & Diego

Frank Shearar-3

Re: Metacello configuration conventions

On 16 April 2013 19:52, stephane ducasse <[hidden email]> 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 integration problems as
> soon as possible.
> If you are in a release mode, you should ensure that your code can run at
> least on fixed dependencies versions (at the best, specify a range of
> versions you can use with possibly no upper limit if your dependencies
> ensure backward compatibility). You need reproducible loading of your
> tool/lib.
>
> in my opinion, you shouldn't use #stable for release version as the only
> thing it ensure (if well tested) is that you will not have a broken version
> of the dependency. The stable version of your dependency will evolve and
> then the configuration of your release too. At a time, your version will not
> be usable at all because of that.
>
> Because even if you milestone against a major version,
> what you mean is that the package may change (and still work on 20 for
> example, but be incompatible with your software).
>
> I will write something in the metacello chapter and see what I wrote on
> symbolic version.
>
> so I would specify a dependency with a versionString for release versions of
> your lib/tool. It ensures a minimum version.
>
>
> So I wonder when we should use stable.
> Versionner will solve all these points for us :)

Well, #stable is for people, not machines. It's how you decide whether
to try Foo 1.3 or Foo 1.4. If you're just using the library, that's
one thing - use other people's #stable releases.

But if you're writing a library, and other people will use your
application (that uses other stuff), that's when tight control over
versions pays off. Your users can know the precise things they need to
run your software.

frank

> Stef
>
>
>
>
> Regards,
> Christophe.
>
> Le 16 avr. 2013 à 11:02, Frank Shearar a écrit :
>
> On 16 April 2013 09:53, Stephan Eggermont <[hidden email]> 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 want to specify the exact version
> that
>
> will be loaded (and has been tested).
>
>
> In the other the #stable version is used. That is an optimistic strategy.
>
> This is much less brittle (but might suddenly not work anymore).
>
>
> Seaside uses defensive/mixed, while Magritte uses optimistic
>
>
> Based on what criteria should I choose which one to use (in a Pharo
> context)?
>
>
> 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, by making such an apparently innocuous change.)
>
> frank
>
> Stephan & Diego
>
>
>
>

Camillo Bruni-3

Re: Metacello configuration conventions

On 2013-04-16, at 23:25, Frank Shearar <[hidden email]> wrote:

> On 16 April 2013 19:52, stephane ducasse <[hidden email]> 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 integration problems as
>> soon as possible.
>> If you are in a release mode, you should ensure that your code can run at
>> least on fixed dependencies versions (at the best, specify a range of
>> versions you can use with possibly no upper limit if your dependencies
>> ensure backward compatibility). You need reproducible loading of your
>> tool/lib.
>>
>> in my opinion, you shouldn't use #stable for release version as the only
>> thing it ensure (if well tested) is that you will not have a broken version
>> of the dependency. The stable version of your dependency will evolve and
>> then the configuration of your release too. At a time, your version will not
>> be usable at all because of that.
>>
>> Because even if you milestone against a major version,
>> what you mean is that the package may change (and still work on 20 for
>> example, but be incompatible with your software).
>>
>> I will write something in the metacello chapter and see what I wrote on
>> symbolic version.
>>
>> so I would specify a dependency with a versionString for release versions of
>> your lib/tool. It ensures a minimum version.
>>
>>
>> So I wonder when we should use stable.
>> Versionner will solve all these points for us :)
>
> Well, #stable is for people, not machines. It's how you decide whether
> to try Foo 1.3 or Foo 1.4. If you're just using the library, that's
> one thing - use other people's #stable releases.
>
> But if you're writing a library, and other people will use your
> application (that uses other stuff), that's when tight control over
> versions pays off. Your users can know the precise things they need to
> run your software.

... and that is more precisely: tests and continuous integration

I liked ruby-gems approach more than the one in Metacello. You usually specify
a major version (as under linux) for your dependency. That means the dependency
might evolve a bit, typically for bugfixes, without you having to update
the configuration manually.

http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see.

As you say, #stable and #development are mostly for humans.

Sean P. DeNigris

Re: Metacello configuration conventions

Administrator

In reply to this post by demarey

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 mode, you should ensure that your code can run at least on fixed dependencies versions

+1 to the two different modes. Dale had recommended to me to depend on #stable in the baseline and then a specific version in the version. I'd say it depends on the underlying project - something like Zinc which seems to always be rock-solid at the bleeding edge I'd probably put #bleedingEdge in the baseline, where a less stable project I might use #stable. But I say definitely, definitely, definitely use a stable version in the version (unless it's a really loose dependency like OB for Seaside) - people need to be able to depend on loading a specific version being repeatedly identical.

Cheers,
Sean

Sean P. DeNigris

Re: Metacello configuration conventions

Administrator

In reply to this post by Camillo Bruni-3

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 get the tools (e.g. Versionner) to use semantic version numbers by default (i.e. new bugfix version, new enhancement version, new incompatible version)

Cheers,
Sean

Camillo Bruni-3

Re: Metacello configuration conventions

On 2013-04-17, at 02:50, "Sean P. DeNigris" <[hidden email]> 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
> depend on the convention being followed? I've been pushing to get the tools
> (e.g. Versionner) to use semantic version numbers by default (i.e. new
> bugfix version, new enhancement version, new incompatible version)

Yeah I think we can run all of that on top of versioner/conventions.
You can always introduce symbolic versions for releases as well so the old
habit of directly referring to a fixed version number will still continue to
work.

demarey

Re: Metacello configuration conventions

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" <[hidden email]> 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
>> depend on the convention being followed? I've been pushing to get the tools
>> (e.g. Versionner) to use semantic version numbers by default (i.e. new
>> bugfix version, new enhancement version, new incompatible version)
>
> Yeah I think we can run all of that on top of versioner/conventions.
> You can always introduce symbolic versions for releases as well so the old
> habit of directly referring to a fixed version number will still continue to
> work.
>

smime.p7s (5K) Download Attachment

Dale Henrichs

Re: Metacello configuration conventions

In reply to this post by Sean P. DeNigris

Sean,

The Metacello Preview will support semantic versioning system as well as the current metacello versioning system ... and one will be able to choose on a project by project basis.

I have all of the version comparison operators implemented for semantic versioning, but at the time I did the implementation there was some ambiguity about sort order for some of the version components (specifically related to pre-release and build versions), but I looked at the spec the other day and it seems that they seem to have clarified the wording ... which means I have to revisit my implementation:)

Doesn't help with ensuring that developers increment the correct version component at the right time:)

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, April 16, 2013 5:50:37 PM
| Subject: Re: [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
| depend on the convention being followed? I've been pushing to get the tools
| (e.g. Versionner) to use semantic version numbers by default (i.e. new
| bugfix version, new enhancement version, new incompatible version)
|
|
|
| -----
| Cheers,
| Sean
| --
| View this message in context:
| http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682036.html
| Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
|
|

Dale Henrichs

Re: Metacello configuration conventions

In reply to this post by Camillo Bruni-3

----- Original Message -----
| From: "Camillo Bruni" <[hidden email]>
| To: [hidden email]
| 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
| specify
| a major version (as under linux) for your dependency. That means the
| dependency
| might evolve a bit, typically for bugfixes, without you having to update
| the configuration manually.
|
| http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see.
|
| As you say, #stable and #development are mostly for humans.

Cami,

I did look at the way ruby-gems worked pretty early on in Metacello development and I've arranged things such that I should be able to add the ability to specify ranges of versions, but the whole mechanics of the ruby-gem universe is different than the smalltalk universe so I'm not sure that Metacello would give you the behavior you are looking for even I did allow version ranges to be specified ...

I'd be willing to spend time working through use cases with you to see if there would be benefit for enabling that feature...

Dale

Sean P. DeNigris

Re: Metacello configuration conventions

Administrator

In reply to this post by Dale Henrichs

Dale Henrichs wrote

The Metacello Preview will support semantic versioning system!

Cool! Thanks Dale :)

Cheers,
Sean

Frank Shearar-3

Re: Metacello configuration conventions

In reply to this post by Dale Henrichs

On 18 April 2013 17:47, Dale Henrichs <[hidden email]> wrote:

>
>
> ----- Original Message -----
> | From: "Camillo Bruni" <[hidden email]>
> | To: [hidden email]
> | 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
> | specify
> | a major version (as under linux) for your dependency. That means the
> | dependency
> | might evolve a bit, typically for bugfixes, without you having to update
> | the configuration manually.
> |
> | http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see.
> |
> | As you say, #stable and #development are mostly for humans.
>
> Cami,
>
> I did look at the way ruby-gems worked pretty early on in Metacello development and I've arranged things such that I should be able to add the ability to specify ranges of versions, but the whole mechanics of the ruby-gem universe is different than the smalltalk universe so I'm not sure that Metacello would give you the behavior you are looking for even I did allow version ranges to be specified ...

What are the differences in mechanics?

frank

> I'd be willing to spend time working through use cases with you to see if there would be benefit for enabling that feature...
>
> Dale
>

stephane ducasse

Re: Metacello configuration conventions

In reply to this post by Dale Henrichs

Dale

I was discussing with christophe yesterday and what would be good in metacello is to be able to have in one version of the configurationOf
all the information about previous heads stable versions because right now to get this information
we need to load previous versions until we see that the stable or development deifnitino changes.

I will start to add to my configurations

previousVersions

^ #((stable 20 #(1.0 1.2 1.3))
(stable 1.4 #(1.0 ))

so that we can perform regression testing and not just test the latest stable version.

Stef

Camillo Bruni-3

Re: Metacello configuration conventions

In reply to this post by Dale Henrichs

On 2013-04-18, at 18:47, Dale Henrichs <[hidden email]> wrote:

yes indeed with the global gem server they have a nice central unit which we
do not have right now. But Christophe and Erwann are working on a first step
towards such a thing for Pharo:
- completely automated configuration validation
- completely automated tests for loaded configurations

But for the version range, I think having that in Metacello would already give
very fine-grained control over dependencies. Additionally it would actually give
real meaning to the version numbers.

DiegoLont

Re: Metacello configuration conventions

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 I usually do not want to upgrade dependencies. If dependencies need upgrading I want to make this decision manually.

In the second I usually want to upgrade dependencies. If dependencies need upgrading this should be done automatically.

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).

Currently we have a baseline, a version, and groups that I can edit. I think I want a third thing: the deployment, where I describe certain deployment strategies. So that I can say:
ConfigurationOfMyProject project stableVersion patch load
ConfigurationOfMyProject project stableVersion loadRelease
or something like this.

Cheers,
Diego

Camillo Bruni-3

Re: Metacello configuration conventions

On 2013-04-19, at 10:36, Diego Lont <[hidden email]> 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 deploy a release, that includes all updates.
>
> In the first I usually do not want to upgrade dependencies. If dependencies need upgrading I want to make this decision manually.
>
> In the second I usually want to upgrade dependencies. If dependencies need upgrading this should be done automatically.
>
> 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).
>
> Currently we have a baseline, a version, and groups that I can edit. I think I want a third thing: the deployment, where I describe certain deployment strategies. So that I can say:
> ConfigurationOfMyProject project stableVersion patch load
> ConfigurationOfMyProject project stableVersion loadRelease
> or something like this.
>
> Cheers,
> Diego

I think you should never hardcode dependencies (well major version number of course)...
but otherwise this is exactly what ruby gems's [1] version constraints will do (~> and friends)

For the inverse, I think that's what you mention, something like Versionner is the only solution.
Since you will have to traverse all dependencies and see which new versions got released
and which ones you want to newly depend on...

[1] http://docs.rubygems.org/read/chapter/16