Andreas/tracks
1
0
Fork 0
mirror of https://github.com/TracksApp/tracks.git synced 2026-02-11 18:04:22 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Convert formatting from Octopress to standard Textile

Browse source
This commit is contained in:
Dan Rice 2013-02-03 11:56:12 -05:00
parent cb3339838e
commit c8d9502f70
2 changed files with 44 additions and 82 deletions
Download patch file Download diff file Expand all files Collapse all files

64
doc/upgrading.textile
View file

@ -1,16 +1,6 @@
---
title: "Manual - Upgrading"
layout: page
comments: false
sharing: false
footer: false
---
h1. Upgrading Tracks
"« Installation":/manual/installation.html
h2. Upgrading Tracks
h3. Upgrading from Tracks 2.1.x/2.2RC to 2.2
h2. Upgrading from Tracks 2.1.x/2.2RC to 2.2
This release adds a variety of new features and bugfixes to Tracks.
@ -28,7 +18,7 @@ To upgrade:
# Run @bundle exec rails server -e production@ inside your Tracks 2.2 directory to start up Tracks 2.2.
# Once you are happy that everything is working well, delete your old Tracks directory.
h3. Upgrading from Tracks 2.1.1 to 2.1.2
h2. Upgrading from Tracks 2.1.1 to 2.1.2
The purpose of this release is to address several security vulnerabilities that were recently discovered in Rails. For details about the contents of the release, please see the "difference view":https://github.com/TracksApp/tracks/compare/v2.1.1...v2.1.2 on GitHub.
@ -42,7 +32,7 @@ There are no changes done to the database, it is therefore not necessary to run
# Once you are happy that everything is working well, delete your old Tracks directory.
h3. Upgrading from Tracks 2.1 to 2.1.1
h2. Upgrading from Tracks 2.1 to 2.1.1
This release is a bugfix release. For details about the fixes, see the "difference view":https://github.com/TracksApp/tracks/compare/v2.1...v2.1.1 on Github.
@ -55,7 +45,7 @@ There are no changes done to the database, it is therefore not necessary to run
# Run @bundle exec script/server@ inside your Tracks 2.1.1 directory to start up Tracks 2.1.1.
# Once you are happy that everything is working well, delete your old Tracks directory.
h3. Upgrading from Tracks 2.0 or 2.1RC1 to 2.1
h2. Upgrading from Tracks 2.0 or 2.1RC1 to 2.1
For the upgrade, please note that with version 2.1 Tracks started to use @bundler@. This means you need to have to install bundler using @gem install bundler@.
@ -78,13 +68,11 @@ If you are running an older version of Tracks (1.8devel), they could also be cal
If you have problems with Passenger not finding the gems bundler installed, you might want to let bundler put all gems in the Tracks directory so that Passenger can find them (and probably have sufficient permissions). Create a directory @.bundle@ in your Tracks root directory. Add the following config in @/path/to/tracks/.bundle/config@:
{% codeblock lang:ruby %}
---
bc. ---
BUNDLE_DISABLE_SHARED_GEMS: "1"
BUNDLE_PATH: /path/to/tracks/.bundle
{% endcodeblock %}
h3. Upgrading from Tracks 2.0RC2 to 2.0
h2. Upgrading from Tracks 2.0RC2 to 2.0
The upgrade to the latest stable 2.0 release consists of the same steps as upgrading from 1.7.x in the following paragraph, just replace 2.0RC with 2.0 where appropriate
@ -92,7 +80,7 @@ PLEASE NOTE that the requirements for Tracks have changes:
# Rubygems needs at least version 1.3.7 or above. 1.3.7 and 1.5.0 are tested. 1.7.0 does not work for this release of Tracks
# Only Ruby 1.8.7 is supported, both 1.8.6 and 1.9.x are not tested and are known to have issues.
h3. Upgrading from Tracks 1.7.x or from 2.0RC1 to Tracks 2.0 final
h2. Upgrading from Tracks 1.7.x or from 2.0RC1 to Tracks 2.0 final
NOTE
# these instructions will work too if you are upgrading to latest 2.0devel tree.
@ -113,18 +101,18 @@ If you did not start with a new copy of Tracks as described above, but installed
If you are running an older version of Tracks (1.8devel), they could also be called jquery-all.js, tracks.js and all.css
h3. Upgrading from Tracks 1.7 or 1.7.1 or 1.7.2 to 1.7.3
h2. Upgrading from Tracks 1.7 or 1.7.1 or 1.7.2 to 1.7.3
The 1.7.1, 1.7.2 and 1.7.3 releases are bug fix releases that do not contain changes to the database structure. You can unzip the new release over your current 1.7 or 1.7.1 install.
It is also possible to follow the instructions below and copy your existing site.yml and database.yml from your Tracks 1.7 install.
h3. Upgrading from Tracks 1.7RC2 to Tracks 1.7
h2. Upgrading from Tracks 1.7RC2 to Tracks 1.7
There were only a few fixes in the code, so you can consider unzipping the new release over your install of Tracks 1.7RC2. Do make a backup of your Tracks 1.7RC2 install and your database!
It is also possible to follow the instructions below and copy your existing Site.yml from your Tracks 1.7RC2 install.
h3. Upgrading from Tracks 1.5, 1.6 or from Tracks 1.7RC1 to Tracks 1.7
h2. Upgrading from Tracks 1.5, 1.6 or from Tracks 1.7RC1 to Tracks 1.7
In Tracks 1.7 (since RC2) the site specific configuration is moved from @environment.rb@ into the new @site.yml@. This makes updating @environment.rb@ much easier without you needing to set your site specific settings after each update.
@ -139,7 +127,7 @@ Also, there were some database changes made in Tracks 1.7, so you need to migrat
# Run @script/server@ inside your Tracks 1.7 directory to start up Tracks 1.7.
# Once you are happy that everything is working well, delete your old Tracks directory.
h3. Upgrading from Tracks 1.043 to 1.7
h2. Upgrading from Tracks 1.043 to 1.7
This should be a relatively straightforward, and involves the following main steps:
@ -150,9 +138,9 @@ This should be a relatively straightforward, and involves the following main ste
# Run @script/server@ inside your Tracks 1.7 directory to start up Tracks 1.7.
# Once you are happy that everything is working well, delete your old Tracks directory.
h3. Detailed steps
h2. Detailed steps
h4. Backing up
h3. Backing up
It's very important that you *back up your database* before you start the upgrade process. It's always possible for things to go wrong with the database update, and you don't want to lose any data. If you are using SQLite3 and you are leaving your old Tracks directory in place, then you don't need to do anything. However, there is no harm in taking extra precautions and copying your database from @/db@ to a safe location as an extra backup, or making a dump of the schema and contents. You will never regret making too many backups! If you are using MySQL, make a SQL dump of your database, replacing the terms in square brackets with the correct information for your setup:
@ -164,21 +152,19 @@ It's very important that you *back up your database* before you start the upgrad
Rename your old Tracks installation (e.g. to 'tracks-old') so that you can install Tracks 1.7 along side it.
h4. Install the latest version of Tracks
h3. Install the latest version of Tracks
There are two methods of downloading Tracks:
# (Recommended for most people) Download the "zipped package":http://bsag.bingodisk.com/public/files/tracks_1.7.zip, and unzip in your preferred location (e.g. @~/Sites@ for Mac OS X users).
# If you want to live on the edge, you can get the latest development version from GitHub using git (bear in mind that this may be less stable than the released versions):
{% codeblock lang:bash %}
cd ~/Sites
bc. cd ~/Sites
git clone git://github.com/TracksApp/tracks.git
cd tracks
{% endcodeblock %}
h4. Copy over old configuration
h3. Copy over old configuration
There are a few settings and configuration files you need to copy over from your old installation. If you copy them over rather than moving them, you can still run your old version of Tracks if anything goes awry with the installation process.
@ -189,36 +175,32 @@ There are a few settings and configuration files you need to copy over from your
# If you are using Windows, you may need to check the 'shebang' lines (@#!/usr/bin/env ruby@) [1] of the @/public/dispatch.*@ files and all the files in the @/script@ directory. They are set to @#!/usr/bin/env ruby@ by default. Check the format of those lines in your old installation, and change the new ones as necessary.
h4. Update your old database to the new format
h3. Update your old database to the new format
In a terminal, change directories so that you are inside the Tracks 1.7 directory. Then issue the command to update your Tracks 1.6 database to the format required for Tracks 1.7:
{% codeblock lang:ruby %}
rake db:migrate RAILS_ENV=production
{% endcodeblock %}
bc. rake db:migrate RAILS_ENV=production
Watch the output carefully for errors, but it should report at the end of the process that everything worked OK. If you do get errors, you'll have to fix them before you proceed any further. Running rake with the @--trace@ option can help to track down the problem.
h4. Start the server
h3. Start the server
If you're still in the Tracks 1.7 root directory in a terminal, enter the following command to start up Tracks in production mode:
{% codeblock lang:ruby %}
script/server -e production
{% endcodeblock %}
bc. script/server -e production
Visit the URL indicated by the output (e.g. @** Mongrel available at 0.0.0.0:3000@
) in a browser, and with any luck, you should be able to log in and find all your actions as you left them! If you need to access Tracks from a mobile/cellular phone browser, visit @http://yourdomain.com/mobile/@. This mobile version is a special, lightweight version of Tracks, designed to use on a mobile browser.
h4. Clean up your old installation
h3. Clean up your old installation
Once you're certain that your new Tracks 1.7 installation is working perfectly, you can delete your old Tracks directory.
h3. Upgrading from versions prior to 1.043
h2. Upgrading from versions prior to 1.043
The best option for versions prior to 1.043 is to follow the instructions below to upgrade to version 1.043, then use the instructions above to upgrade from version 1.043.