Jonathan, Agree completely, and the new tagging represents everyone's patches (including a couple of compatible changes of my own) are in 2.5.
I don't like that out of the box, even for people deploying a rails application on Passenger Mod_Rails, will throw an error if there's no script/spin, even when using mongrel - I have never been able to get script/spin to work.. so I feel that at least should go. And Rails isn't the Ruby framework anymore, I certainly loath having to remember which tasks to disable to deploy a Sinatra app, and beginners who don't grok the Capistrano internals as well as the maintainers and contributors. I don't so much consider it to be stack-aware, as load-your-own, and the changes I am proposing (and have working) for the *potential* 2.6.0 release are *clearly* documented in the capfile, it is unmissable. Perhaps I have dropped the ball by not implementing the tasks in the default deploy.rb as "Deprecated see the readme"; I have thoroughly tested the 2.6.0 (as we're now calling it) release, and don't think that removing some tasks that are often disabled or re-implemented by experienced users, to help inexperienced users is a massive problem. I won't be actually releasing anything until we resolve the discussion; it really depends what people deploy most often with Capistrano, I very very rarely deploy a Rails application to a mongrel stack, and very often deploy PHP apps to vanilla Apache, and Sinatra and Rails apps to Passenger Mod_Rails; with that in mind, I don't see why removing some magic, making it easier for people to enjoy cap, and get started more easily is a problem. I can see the argument for not putting this in a x.x.Y release, that was a really short-sighted bit of version numbering on my part, and I don't want to break anyone's valuable deploys, but I do believe that this change is for the better. And if it works well, simplifies the writing and distribution of `extensions` not unlike the multistage package. - Lee 2009/5/27 Jonathan Weiss <[email protected]> > > Hi Lee, > > > I look forward to any more feedback, positive or negative or otherwise: > > I agree with everybody else that the 2.5 line shouldn't have any > incompabitle changes. > > >.. why has all this stuff gone? Well the migrations, and shared children, > everyone deploying Rails needs, but anyone using > > Sinatra, PHP, python or similar.. ends up having to skip loading > `deploy.rb` and not even getting the versioned deploy code. > > Now, out of the box, a deploy will make a new release directory, use your > deploy:strategy to get the code into it and then update > the symlink. There > is more in the CHANGELOG.rdoc > > This is not my experience, I see most people just overrding the > deploy:{start|stop|restart} tasks with NOPs. > > I think that an app-stack aware extension to Capistrano is really > useful, but I'm not sure this is the right way. I've been very busy > the last weeks with conferences and will look over the changes over > the coming days. Maybe we should start a discussion on the desired API > first (what and how people want to use app-stack aware extensions) and > then start the implementation. > > Because we are breaking/changing the default behavior this would also > be more stuff for a 3.0 release. > > Jonathan > > -- > Jonathan Weiss > http://blog.innerewut.de > http://twitter.com/jweiss > > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
