Can you comment on the nature of the delicacy? Will I not be able to rely on this in future versions to essentially reset the state of the Capfile during runtime? Not being in Ruby land, I'm much more concerned about relying on the internals of the Capistrano API (like reset! of @variables) that might change than I am about higher level kludges (deploying different pieces to different servers). So far, Capistrano has been extremely helpful in replacing the myriad shell scripts that I have written in the past to do this type of deployment and I'd love to continue using it as long as I'm not putting myself in danger of having a broken script in a point release.
The future versions of Capistrano sound very promising. A general deployment DSL would be extremely helpful. Thanks for all your help. On Nov 2, 1:03 pm, Lee Hambley <lee.hamb...@gmail.com> wrote: > Looks like a pretty delicate hack to me, and that whilst this stuff lives in > the same repo, it's deployed to different servers, in different > configurations. In Ruby land, that's a smell that your repos are merged, and > you should break them out. > > One of the overriding philosophies of Capistano is that a deploy should be > atomic and repeatable… so "I want to deploy bits and pieces at various > times, to various places" will always be a kludge. > > In future versions the Capistrano core is being reduced to a selection of > useful helpers, with sane scaffolding and defaults, this should lead to a > situation where it's significantly easier for you to build what you need, > without having to deal with so much nonsense. > > - Lee -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to capistrano@googlegroups.com * To unsubscribe from this group, send email to capistrano+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
