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: >> 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... > > > [1] http://docs.rubygems.org/read/chapter/16
