Tonight I asked on IRC: "How do I upgrade?"
Multiple Reponses: "cd RAILS_ROOT; rails ."
So I tried it.. it wasn''t pretty :) not awful mind you.. but..
I think a better upgrade solution could go a long way in easing users''
pain in dealing with frequent rails updates. Therefore, I propose the
following document as a starting point to such instructions. Feel free to
add to this, delete it, put it on the Wiki, or completely ignore it..
Thanks for rails.
--Steve
--------------------------------------------------------------
Even a stopped clock gives the right time twice a day...
--------------------------------------------------------------
Upgrading Rails
==============
The nature of rails and the rails development community is one of
fluidity, rapid application development, and ease of use. Rails, as of
today (April ''05''), is very rapidly changing. Therefore,
upgrades to new
versions should be as painless as possile.
This document intends to describe a safe, simple, painless upgrade
procedure when moving from one version of rails to the next.
Prerequisites
-------------
You will need to maintain a "pristine" (i.e. default) rails install.
So,
when you first create your application, you''d also create a sibling app
named "pristine", for example:
rails MyApp
rails MyApp-pristine
If you didn''t create this pristine environment when you first created
your
rails application.. don''t worry. You can still create it - just do it
*before* upgrading your rails (described in Step 1 below).
Update Procedure
----------------
1. Get new rails
gem update rails
2. Save off all of your edits
cd MyApp
diff -crN ../MyApp-pristine . > ../MyApp.edits
cd ..
3. Create new rails installs
rails NewMyApp
rails NewMyApp-pristine
4. Apply your edits to the new install
cd NewMyApp
patch -p0 < ../MyApp.edits
5. Test.. If OK, archive or remove the old version
New install OK?
tar zcvf MyApp-archive.tar.gz MyApp MyApp-pristine MyApp.edits
rm -rf MyApp MyApp-pristine MyApp.edits
mv NewMyApp MyApp
mv NewMyApp-pristine MyApp-pristine
Closing Notes, Comments on the Future
-------------------------------------
Now, I actually believe rails could automate this, given it is to able
determine the prior version of rails and that the prior version is still
installed. Basically, it''d have to establish access to the old version
of
a file (say application.rb), the new version of that file, and the current
(possibly user edited) version. It could then simply run merge
''old-application.rb new-application.rb user-application.rb'' -
but it''d be
great if this could happen inside Ruby. Perhaps the
''diff-lcs'' gem could
be helpful?
When all of this magic happens, we might change the above instructions to
simply read:
rails upgrade MyApp
Note, updated doc at:
http://www.swaits.com/index.cgi/2005/04/20#UpgradingRails
--Steve
--------------------------------------------------------------
Even a stopped clock gives the right time twice a day...
--------------------------------------------------------------
I think this is a great idea... I had to manually go and merge all my modified files when I did an upgrade. It was a new project, so there weren''t too many things to change, but it was still a pain. It would be great if this was automated. What would the automated upgrader do if it detects a conflict? On 4/21/05, Stephen Waits <swaits-g8GSkY9QmIteoWH0uzbU5w@public.gmane.org> wrote:> > Note, updated doc at: > > http://www.swaits.com/index.cgi/2005/04/20#UpgradingRails > > --Steve > > -------------------------------------------------------------- > Even a stopped clock gives the right time twice a day... > -------------------------------------------------------------- > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- - Ramin http://www.getintothis.com/blog
I use a slightly different method. I put my Rails app in a Subversion
repository. Then, when I upgrade ("cd my/app/base; rails .") I let it
change whatever it likes. Now I can diff any file from the previous
version, and I can revert back to that version if I choose.
Normal files to watch are config/database.yml, config/environment.rb,
and config/routes.rb. I will diff those right away, and usually revert
them back because nothing new was added and my settings would be lost if
I didn''t.
Now run "rake" and make sure all the tests pass. Run the app and test
things. If all is good, just commit to the repository.
My thinking is that if I''m going to maintain multiple
"versions" of some
code, I''d rather use a "version control system" that has
functions for
comparing versions and recovering previous versions.
Stephen Waits wrote:>
> Tonight I asked on IRC: "How do I upgrade?"
> Multiple Reponses: "cd RAILS_ROOT; rails ."
>
> So I tried it.. it wasn''t pretty :) not awful mind you.. but..
>
> I think a better upgrade solution could go a long way in easing
users''
> pain in dealing with frequent rails updates. Therefore, I propose the
> following document as a starting point to such instructions. Feel free
> to add to this, delete it, put it on the Wiki, or completely ignore it..
>
> Thanks for rails.
>
> --Steve
>
> --------------------------------------------------------------
> Even a stopped clock gives the right time twice a day...
> --------------------------------------------------------------
>
>
>
> Upgrading Rails
> ==============>
> The nature of rails and the rails development community is one of
> fluidity, rapid application development, and ease of use. Rails, as of
> today (April ''05''), is very rapidly changing. Therefore,
upgrades to new
> versions should be as painless as possile.
>
> This document intends to describe a safe, simple, painless upgrade
> procedure when moving from one version of rails to the next.
>
>
> Prerequisites
> -------------
>
> You will need to maintain a "pristine" (i.e. default) rails
install. So,
> when you first create your application, you''d also create a
sibling app
> named "pristine", for example:
>
> rails MyApp
> rails MyApp-pristine
>
> If you didn''t create this pristine environment when you first
created your
> rails application.. don''t worry. You can still create it - just
do it
> *before* upgrading your rails (described in Step 1 below).
>
>
> Update Procedure
> ----------------
>
> 1. Get new rails
>
> gem update rails
>
> 2. Save off all of your edits
>
> cd MyApp
> diff -crN ../MyApp-pristine . > ../MyApp.edits
> cd ..
>
> 3. Create new rails installs
>
> rails NewMyApp
> rails NewMyApp-pristine
>
> 4. Apply your edits to the new install
>
> cd NewMyApp
> patch -p0 < ../MyApp.edits
>
> 5. Test.. If OK, archive or remove the old version
>
> New install OK?
> tar zcvf MyApp-archive.tar.gz MyApp MyApp-pristine MyApp.edits
> rm -rf MyApp MyApp-pristine MyApp.edits
> mv NewMyApp MyApp
> mv NewMyApp-pristine MyApp-pristine
>
>
> Closing Notes, Comments on the Future
> -------------------------------------
>
> Now, I actually believe rails could automate this, given it is to able
> determine the prior version of rails and that the prior version is still
> installed. Basically, it''d have to establish access to the old
version of
> a file (say application.rb), the new version of that file, and the current
> (possibly user edited) version. It could then simply run merge
> ''old-application.rb new-application.rb
user-application.rb'' - but it''d be
> great if this could happen inside Ruby. Perhaps the
''diff-lcs'' gem could
> be helpful?
>
> When all of this magic happens, we might change the above instructions to
> simply read:
>
> rails upgrade MyApp
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
----------
Scanned for viruses by ClamAV
On Thu, 21 Apr 2005, Ramin wrote:> What would the automated upgrader do if it detects a conflict?I think the same thing that regular `merge` does - insert some tag about the conflict and emit a diagnostic to stderr. --Steve
On Thu, 21 Apr 2005, Kevin Williams wrote:> I use a slightly different method. I put my Rails app in a Subversion > repository. Then, when I upgrade ("cd my/app/base; rails .") I let it > change whatever it likes. Now I can diff any file from the previous > version, and I can revert back to that version if I choose.Well.. this is still a rather manual process when it comes down to it. It does simplify the "tell me what''s different" part; however, it also requires you to then manually go through and either revert, or merge changes back in. Besides that.. most users will be subversion averse. --Steve
On Wed, 20 Apr 2005, Stephen Waits wrote:> Note, updated doc at: > > http://www.swaits.com/index.cgi/2005/04/20#UpgradingRails [DEPRECATED]That link is invalidated.. now it''s here: http://www.swaits.com/index.cgi/2005/04/21#UpgradingRails Thanks to Chris Boone for pointing out that my upgrade instructions didn''t deal with binary files. See the new link for updated instructions. --Steve -------------------------------------------------------------- Even a stopped clock gives the right time twice a day... --------------------------------------------------------------
Stephen Waits wrote:> > On Thu, 21 Apr 2005, Kevin Williams wrote: > >> I use a slightly different method. I put my Rails app in a Subversion >> repository. Then, when I upgrade ("cd my/app/base; rails .") I let it >> change whatever it likes. Now I can diff any file from the previous >> version, and I can revert back to that version if I choose. > > > Well.. this is still a rather manual process when it comes down to it. > It does simplify the "tell me what''s different" part; however, it also > requires you to then manually go through and either revert, or merge > changes back in.I gain failure control and only have one file tree to maintain, though. Plus, I can do all of this without network access, except commit.> > Besides that.. most users will be subversion averse.I don''t know about "most users". Everyone I know uses source control of some type, and most of them use svn. Rails is on svn, for that matter. Of course, I don''t know many people, including most everyone on this list. ;) Just a suggestion, especially for laptop users or those with a hot delete key trigger finger.> > --Steve > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails---------- Scanned for viruses by ClamAV
On Thu, 21 Apr 2005, Kevin Williams wrote:> I gain failure control and only have one file tree to maintain, though. > Plus, I can do all of this without network access, except commit.My ''system'' doesn''t destroy anything either.>> Besides that.. most users will be subversion averse. > > I don''t know about "most users". Everyone I know uses source control of > some type, and most of them use svn. Rails is on svn, for that matter. > > Of course, I don''t know many people, including most everyone on this > list. ;)I''d say the broad market of your "average PHP or ASP coder" has never touched svn, or cvs, p4, bk, etc.. I just don''t see your average coder using svn.. sorry. I also believe rails is destined for this ''market''. Anyway.. I''m not arguing for or against anything other than to say that the current suggested upgrade of `cd RAILS_ROOT; rails .` is poor and possibly very destructive.. My idea was to provide something simple that actually does upgrade your app. --Steve
> > On Thu, 21 Apr 2005, Kevin Williams wrote: > >> I gain failure control and only have one file tree to maintain, though. >> Plus, I can do all of this without network access, except commit. > > My ''system'' doesn''t destroy anything either. > >>> Besides that.. most users will be subversion averse. >> >> I don''t know about "most users". Everyone I know uses source control of >> some type, and most of them use svn. Rails is on svn, for that matter. >> >> Of course, I don''t know many people, including most everyone on this >> list. ;) > > I''d say the broad market of your "average PHP or ASP coder" has never > touched svn, or cvs, p4, bk, etc.. I just don''t see your average coder > using svn.. sorry.Rails has the attention of enterprise-level Java and .NET coders, too.> > I also believe rails is destined for this ''market''. > > Anyway.. I''m not arguing for or against anything other than to say that > the current suggested upgrade of `cd RAILS_ROOT; rails .` is poor and > possibly very destructive.. > > My idea was to provide something simple that actually does upgrade your > app.I didn''t mean to offend you or anyone else, just offer an alternate way of doing things. With a source control solution, the fear of "rails ." being destructive is not necessary. I''m not saying your solution is wrong or not helpful.> > --Steve > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >---------- Scanned for viruses by ClamAV
On Thu, 21 Apr 2005, Kevin Williams wrote:> I didn''t mean to offend you or anyone else, just offer an alternate way > of doing things. With a source control solution, the fear of "rails ." > being destructive is not necessary. I''m not saying your solution is > wrong or not helpful.Oh no offense! We all have a common goal.. arriving at that goal involves discussion! Realistically, it''d be ignorant to NOT have revision control on your rails projects - but the world is full of ignorant people. :) --Steve
On 21/04/2005, at 4:08 PM, Stephen Waits wrote:> I think a better upgrade solution could go a long way in easing users'' > pain in dealing with frequent rails updates. Therefore, I propose the > following document as a starting point to such instructions. Feel > free to add to this, delete it, put it on the Wiki, or completely > ignore it..Pre 1.0 there''s no point providing smoother upgrades... IMO effort is better spent elsewhere. ... though it''s probably a good time to discuss requirements for distributing and performing 1.0+ upgrades =) - tim
Steve, On 22.4.2005, at 01:19, Stephen Waits wrote:> > Oh no offense! We all have a common goal.. arriving at that goal > involves discussion! > > Realistically, it''d be ignorant to NOT have revision control on your > rails projects - but the world is full of ignorant people. :)One of Rails'' mantras is "Best practices by invitation" [1]. So why not shed some light on these ignorant people? I think we shouldn''t lead them to inferior paths only because it''s a bit more work now (and a lot less headache later). The fact that they didn''t use source control before doesn''t mean they shouldn''t start right away. Of course the big question is how we could invite people start using svn effortlessly. One great example is Textdrive where you can easily create and manage svn repositories through a simple (but ugly) web interface. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Oops, [1] was supposed to be http://media.nextangle.com/rails/ror2bc.pdf :-) //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Friday, April 22, 2005, 5:36:09 PM, Tim wrote:>> I think a better upgrade solution could go a long way in easing users'' >> pain in dealing with frequent rails updates. Therefore, I propose the >> following document as a starting point to such instructions. Feel >> free to add to this, delete it, put it on the Wiki, or completely >> ignore it..> Pre 1.0 there''s no point providing smoother upgrades... IMO effort is > better spent elsewhere.I agree that an automatic tool is not worth it at this stage, but the ingredients of Stephen''s document were useful as a guide to manual updating. That document should be in the hieraki on rubyonrails.com, IMO. Gavin
Sorry, but link doesn''t work for me. I''m collecting all types of document about RoR, and I''m not sure I''ve got this :-). -- Pepe On 22.4.2005, at 9:48, Jarkko Laine wrote:> Oops, [1] was supposed to be > http://media.nextangle.com/rails/ror2bc.pdf > > :-) > > //jarkko > > -- > Jarkko Laine > http://jlaine.net > http://odesign.fi > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 25.4.2005, at 11:04, Josef Pospíšil wrote:> Sorry, but link doesn''t work for me. I''m collecting all types of > document about RoR, and I''m not sure I''ve got this :-).Weird, it works just fine with me. Could you retry and if it isn''t working tell exactly what error you''re getting? //jarkko> > -- > Pepe > On 22.4.2005, at 9:48, Jarkko Laine wrote: > >> Oops, [1] was supposed to be >> http://media.nextangle.com/rails/ror2bc.pdf >> >> :-) >> >> //jarkko >> >> -- >> Jarkko Laine >> http://jlaine.net >> http://odesign.fi >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails