Jonathan Weiss a écrit : > Hi Lee, > > I agree that there should be an app-stack aware Capistrano where you > define your stack and get much better defaults. > > I totally agree with the goal of making deploying non-rails (and > non-spin) applications easier but I think it should be done more > unobtrusive than now and it shouldn't break existing deployments for a > 2.x release. > > [snip] > Hello,
I didn't yet review the proposed release(s) so please correct me if I got some points wrong. First, I fully agree a minor point release should not contain important changes, only bugfixes. I'm saying this a bit late thought as Lee already changed his plans for the 2.5.6 version. For the next version (2.6 ? 3.0 ?) I think changing the default recipe to deploy without rails specific defaults (and even without any application/langage specific default, I'm thinking static site here) is a reasonable choice. Almost everyone is already rewriting the start/stop/restart tasks, but there are many other changes required or welcomed if you are not deploying a rails app : - The deploy:migrate and deploy:migrations is obviously rails specific (or at least activerecord specific ? I don't know about merb migrations) - The deploy recipe creates the system/log/pids shared directories (using the shared_children var), but log and pids may not be used (even with a rails app, when you're using passenger). - An other rails default is in the finalize_update task which assumes there is a public directory, with images, stylesheets, and javascripts subdirectories (this task also symlinks the shared/system dir and the tmp and tmp/logs directories) - The web:disable and web:enable tasks also uses the system directory assuming the public/system/maintenance.html file will be check and used at the web server level - I should also repeat that (re)creating empty restart/start/stop tasks seems ugly and feel like a hack That said, I understand such changes in the defaults should not be rushed. Taking note that many people are using the deploy recipe as a base for creating their own, my proposal would be : - Publicly release the 2.5.6 version with the bugfixes only - Have a "transitional" release (2.6 ?) that splits the deploy tasks in two recipes : 'deploy/core' (or 'base' ?) would contain the basic deployment tasks, usable as is for a static website (and should work for a PHP website); and 'deploy/rails' include the necessary tasks and hooks for rails deployments. Theses rails tasks should not be changed (so script/spin would still be used). The 'deploy' recipe should include the core and rails files, and throw a warning informing the user of theses changes. - In the future releases (3.x ?), have the 'deploy' recipe only load 'deploy/core'. This would also be the time for discussing important recipe changes and code cleanups. Some recipes could be also added, including 'deploy/mongrel', 'deploy/passenger', 'deploy/wordpress' (which would symlink the correct assets dir), etc (I have many other ideas but this is another topic :-) ). Please note I am not aware about any inconvenience this "release plan" may have, but I think this is a good compromise between changing defaults and providing some sort of transition. What do you think ? PS: I apologize in advance if my English sucks or some sentences does not have any sense, some of the ideas are in my head for a while but I'm writing this as I think ;) PS2: Thanks Lee (and others !) for "taking over" the capistrano project and keeping it alive, this is important for the rails community and ruby community, and even beyond. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
