[Pharo-project] 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
On 16 April 2013 09:53, Stephan Eggermont <stephan@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, 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
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 <stephan@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, 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
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 <stephan@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, 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
On 16 April 2013 19:52, stephane ducasse <stephane.ducasse@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 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 <stephan@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, 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
On 2013-04-16, at 23:25, Frank Shearar <frank.shearar@gmail.com> wrote:
On 16 April 2013 19:52, stephane ducasse <stephane.ducasse@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 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.
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.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 2013-04-17, at 02:50, "Sean P. DeNigris" <sean@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*, 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.
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" <sean@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*, 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.
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" <sean@clipperadams.com> | To: pharo-project@lists.gforge.inria.fr | 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.... | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | |
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.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
----- Original Message ----- | From: "Camillo Bruni" <camillobruni@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 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
On 18 April 2013 17:47, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Camillo Bruni" <camillobruni@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 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
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
----- Original Message ----- | From: "Camillo Bruni" <camillobruni@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 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
On 2013-04-18, at 18:47, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Camillo Bruni" <camillobruni@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 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...
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.
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
On 2013-04-19, at 10:36, Diego Lont <diego.lont@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. 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
On 19 April 2013 09:55, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-04-19, at 10:36, Diego Lont <diego.lont@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. 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)
I agree with the idea: you'd automatically pull in bugfixes and such. However, there's now also nothing protecting you from being bitten by people not following semantic versioning, accidental regressions in your dependencies, new bugs, ... You make your builds unrepeatable. The point of a Gemfile.lock is to turn your ~> dependencies in your Gemfile into hard dependencies, so you can control this accidental uprev. Or, at the least, show the uprev explicitly. But Gemfile.lock only gets refreshed when you "bundle install" or "bundle update", so do also get to _decide_ whether or not to uprev. frank
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...
On 2013-04-19, at 11:04, Frank Shearar <frank.shearar@gmail.com> wrote:
On 19 April 2013 09:55, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-04-19, at 10:36, Diego Lont <diego.lont@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. 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)
I agree with the idea: you'd automatically pull in bugfixes and such. However, there's now also nothing protecting you from being bitten by people not following semantic versioning, accidental regressions in your dependencies, new bugs, ... You make your builds unrepeatable.
well no need to repeat that over and over again. Fixed dependencies DO work perfectly in Metacello. Automatic dependencies DO NOT work currently.
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 new version, if you do, you manually change them. Either way, you make a new version, whether it's a patch, enhancement, or total overhaul.
The symbolic versions, OTOH, map your versions to their status on respective platforms. You would do this for every new version. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682563.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sean, 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. "automatic dependencies" actually only work (and you'll like this Sean) if the project is using Semantic Versioning[1]. If a project doesn't follow the semantic version specification for version numbering, then version ranges are also meaningless. One MUST be able to look at a version number and be able to distinguish between API changes, backwards compatible functionality changes and backwards compatible bugfixes ... If a project follows this convention, then one can specify a dependency that allows for updating only for bugfixes ... In the absence of any version name convention, one must be explicit ... I imagine that today, very few projects actually apply Semantic Versioning to their version numbering scheme, so we must start by adopting Semantic Versioning ... Metacello can handle the mechanics of Semantic Versioning, but it is up to the developers to adhere to the specification. Dale [1] http://semver.org/ ----- Original Message ----- | From: "Sean P. DeNigris" <sean@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 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 new version, if you do, you | manually change them. Either way, you make a new version, whether it's a | patch, enhancement, or total overhaul. | | The symbolic versions, OTOH, map your versions to their status on respective | platforms. You would do this for every new version. | | | | ----- | Cheers, | Sean | -- | View this message in context: | http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682563.... | Sent from the Pharo Smalltalk mailing list archive at Nabble.com
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 had some conversations on the Metacello mailing list about it. I was answering Diego! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-configuration-conventions-tp4681777p4683009.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Diego, You raise some good points here ... In the Metacello Scripting API, I have added some capabilities that just might fill the bill. For example you can write the following expression: Metacello image configuration: 'MyProject'; version: '1.0.1'; onUpgrade: [:ex | ex deny]; load. The onUpgrade block is evaluated whenever Metacello detects an upgrade of a project ... the exception is an instance of MetacelloResolveProjectUpgrade which is Notification that provides information about the current in-image project (version name, etc.) and the proposed incoming version, so you can be very fine grained in your control. In addition there are #onDowngrade: and #onConflict: variants as well.. The Metacello Scripting API needs to be ported to Pharo 2.0 (Christophe and I are working on this ... I am very busy right now so I won't be moving fast here:), but it does run fine in GemStone, Pharo1.1-1.4, and Squeak4.3-4.5 ... I haven't release the Metacello Scripting API, because I just haven't the kind of feedback that I'd like when introducing a new API like this (if you look closely at the above expression, you might have several questions about details of the API). There are a number of folks that are using the Metacello Scripting API, but I haven't gotten enough bug reports to tell me that folks are really beating on it:). I've been using it myself for about 8 months, but I work in a limited number of use cases. 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 the port, otherwise you can take it for a spin[1] (there is some documentation as well) and let me know what makes sense to you and what doesn't. I'm prepared for the fact that when folks take a look at the Scripting API, I will need to make significant changes to the API so you should be prepared for that as well:) Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/README.md ----- Original Message ----- | From: "Diego Lont" <diego.lont@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 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 |
On 22 Apr 2013, at 17:37, Dale Henrichs <dhenrich@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 I to finish the port, otherwise you can take it for a spin[1] (there is some documentation as well) and let me know what makes sense to you and what doesn't.
We're using the scripting api since almost a year and it seems to behave :-) Btw, I also did some work to make it run in Pharo2.0 but it's not yet working entirely. What is the location of your code changes on this so I can merge in when I get back to it? Btw, I did run into some load problems where strange conflicts got reported in gemstone... you might be getting that bug report sooner than you want ;-) Cheers Johan
Cami, I will look into this a bit and put together a straw man proposal for what it would look like and you guys can refine that into something you can use ... Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Thursday, April 18, 2013 12:57:47 PM | Subject: Re: [Pharo-project] Metacello configuration conventions | | | On 2013-04-18, at 18:47, Dale Henrichs <dhenrich@vmware.com> wrote: | | > | > | > ----- Original Message ----- | > | From: "Camillo Bruni" <camillobruni@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 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... | | 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. |
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 -- View this message in context: http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682035.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (9)
-
Camillo Bruni -
Christophe Demarey -
Dale Henrichs -
Diego Lont -
Frank Shearar -
Johan Brichau -
Sean P. DeNigris -
Stephan Eggermont -
stephane ducasse