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