1.1 to 1.2 migration
This page is intended to specify what you'll need to do to move from 1.1.x to 1.2, which should be available sometime in December 2011.
As of 1.2 the i18n code will be merged into the master code base. This will be mostly invisible to you if you're using a single locale English installation. If you plan to use a multiple locale installation you'll want to take a look at the i18n page (also note that you'll still have to provide appropriate localizations yourself, although we hope that as people do this we'll be able to accumulate a collection pre-made ones) . However, the mere process of doing i18n to Bibapp provided some opportunities for code clean up that will be reflected in all installations. As a result some of the configuration is done a bit differently.
There are also some migrations that need to be run.
There are a few migrations to run. Standard precautions are advisable - back up your database before doing anything.
Most of the new migrations handle i18n issues, but there is also one that makes the publication date for a work more flexible. Some of these migrations affect not only the database structure but also operate on the data in the database itself. One of them does it through Ruby/Rails (unless you are using Postgres) - this migration takes the publication_date of each work and splits it up, storing the individual parts and may be slow (on my development machine it processes about 750 works per minute). Also, since it is working through Rails on Works, bibapp needs to be started (in particular Solr needs to be available) before running the migration.
With that preamble, the steps you'll need to take are:
This is the same as any update and depends on your particular set up. If you use Capistrano then this should happen as part of a normal Capistrano deploy. If you maintain things manually from git then it should just be pulling the new code for master or the tag you'll be using.
bundle exec rake bibapp:restart from the Bibapp installation root. If you use Capistrano you may have set this up to
happen automatically or via a cap task.
As previously mentioned, this step may take a while to run, so be prepared for that. If you use Postgres then the necessary action takes place in SQL rather than Rails, so it's quick. If you use another database and are so inclined (and know what you're doing) feel free to alter the migration in db/20111111201022_split_publication_date_in_works.rb to achieve the same end in SQL for your database. The Postgres code therein should make it clear what we are expecting to happen.
bundle exec rake db:migrate from the Bibapp installation root. Note that Capistrano does not migrate automatically, so if you use Capistrano and haven't altered your scripts to do it automatically you'll need to cap deploy:migrate.
There is a new configuration file, locales.yml in config/, and a corresponding example file. Copy the example to locales.yml and edit it to contain a list of the locales you want to use (and for which you plan to provide locale files in your setup) with the default locale first in the list. It is preferred to do this even if you plan on a one locale English installation, although if the locales.yml file isn't found Bibapp will default to that.
The i18n machinery provides better ways to inject and localize custom strings into the application than personalize.rb did. Therefore some of the information that you previously had in personalize.rb will now move elsewhere. The general guideline is as suggested above - display strings will move and become localizable (e.g. names, tagline) , whereas things that should only have a single configuration remain in personalize.rb (e.g. the sysadmin email). If you look at personalize.rb.example after updating the code you'll see notes about what has moved and variables that have moved will now be commented out in that file. There is no harm in leaving the variables in personalize.rb after you've moved them, but they can be deleted if you wish.
The destination for personalization information is config/locales/personalize. For each locale in your Bibapp you'll have a file here with the personalization strings. There is an en.yml.example file. Copy this into en.yml in the same directory and edit as desired. For other locales copy to the appropriate file in the same directory (e.g. for German you'd make a de.yml file in config/locales/personalize) and edit.
After you have this file in place I think you'll have to restart your Rails server for it to pick up the strings. Actually I think a production server will need to restart whenever there are changes to the localization strings.
If you deploy code automatically you'll want to manage this file and any other file in config/locale that you insert or modify via your deployment scripts somehow, much like any other config file.
1.2 has a feature that allows you to exclude certain keywords that you specify from tag clouds. If you want to use this then copy config/keyword_exclusions.yml.example to config/keyword_exclusions.yml and edit accordingly. If you don't need this things should function normally with no action on your part.
This feature was first incorporated by Jason Stirnaman and from what I know he runs the kind of Bibapp where you'd expect it to be potentially useful - where the works collected are sufficiently specialize that you'd expect a small collection of keywords to be common to many of the works, but where these keywords are kind of implicit because of the scope of the installation.