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.