Surely the whole point about a test/staging system is any glitches won't impact on the production system. Mixing them the way you suggest would mean any problems with the test system would also impact the live one. Would this not be self defeating ? Sent from MyPhone
David Carter dpc22@cam.ac.uk wrote:
We expect to upgrade from Roundcube 0.9.5 to 1.0.x over the summer vacation (my management chain and I prefer not to make substantial changes during the academic year).
Something that I would like to do if possible is have a period of parallel running so that people can kick the tires and make sure that our small collection of local plugins and our local skin are working correctly for a few days or weeks before we commit to running the new version.
I can of course dump and restore the existing Roundcube database to build a completely independent Roundcube 1.0.1 test system off to one side, away from the production servers.
However if I look at the handful of database upgrade steps from 0.9.5 to 1.0.1, the only significant change would appear to be the attached renaming of sequences (we aren't using any of the cache tables).
.../SQL/postgres/2013042700.sql :
ALTER SEQUENCE user_ids RENAME TO users_seq; ALTER TABLE users ALTER COLUMN user_id SET DEFAULT nextval('users_seq'::text);
ALTER SEQUENCE identity_ids RENAME TO identities_seq; ALTER TABLE identities ALTER COLUMN identity_id SET DEFAULT nextval('identities_seq'::text);
ALTER SEQUENCE contact_ids RENAME TO contacts_seq; ALTER TABLE contacts ALTER COLUMN contact_id SET DEFAULT nextval('contacts_seq'::text);
ALTER SEQUENCE contactgroups_ids RENAME TO contactgroups_seq; ALTER TABLE contactgroups ALTER COLUMN contactgroup_id SET DEFAULT nextval('contactgroups_seq'::text);
ALTER SEQUENCE search_ids RENAME TO searches_seq; ALTER TABLE searches ALTER COLUMN search_id SET DEFAULT nextval('searches_seq'::text);
These sequence names appear to be hard-wired in 1.0.1.
However Roundcube 0.9.5 can be reconfigured to use any names, including the names used by 1.0.1:
// you can define specific sequence names used in PostgreSQL $rcmail_config['db_sequence_users'] = 'users_seq'; $rcmail_config['db_sequence_identities'] = 'identities_seq'; $rcmail_config['db_sequence_contacts'] = 'contacts_seq'; $rcmail_config['db_sequence_contactgroups'] = 'contactgroups_seq'; $rcmail_config['db_sequence_searches'] = 'searches_seq';
A brief experiment on a test system suggests that I can safely switch back and forth between Roundcube 0.9.5 and 1.0.1 with this single configuration change at the 0.9.5 end.
My question is whether this is a sensible thing to try and do. Are there incompatible changes in the various preferences databases which aren't reflected in the database schema? That would require an independent test system.
Thanks,
-- David Carter Email: David.Carter@uis.cam.ac.uk University of Cambridge, Phone: (01223) 334502 Information Services, Fax: (01223) 334679 7 J J Thomson Avenue, Cambridge UK. CB3 0RB
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
On 2014-05-22 15:24, Steve Perkins wrote:
Surely the whole point about a test/staging system is any glitches won't impact on the production system. Mixing them the way you suggest would mean any problems with the test system would also impact the live one. Would this not be self defeating ?
Quite possibly, yes. I'm just thinking through options at the moment.
I imagine that the base functionality in Roundcube 1.0.x has been reasonably well tested at this point: I am more interested in making sure that our local plugins (which don't really touch the database) and theme work.
The disadvantage of a independent test system is that database updates there won't be reflected on the live system. This will discourage people from trying to use it.
Ultimately I just don't like big bang upgrades, and try to avoid them where possible.