Now we've bridged the gap and provide an upgrade path for each historic schema
revision of this plugin, while data migration is incomplete yet, especially
regarding subscription attributes stored in session_attribute (before v3).
Due to component name changes the conversion will be rather complicated, and
therefore corresponding research and development is postponed to a future date
and will largely depend on explicite demand as well.

TracAnnouncer: Part 5 of 7 - Care for some schema adjustments, refs #5774 and #9742.

Early adopters beware: The long-awaited script for data migration fromsubscriptions to subscription and subscription_attribute db tables
is still a pending issue, that requires even more investigation.

Currently the upgrade procedure just drops the old table irrevocably,
following corresponding historic schema changes, hereby labeled as revision 4.
Make sure to backup your db before upgrading, if you still put faith into
recovering some old user settings later on - you've been warned twice now.

TracAnnouncer: Part 3 of 7 - Follow historic footsteps in schema development for this plugin, refs #5774 and #9742.

The schema discovery logic already leaks a bit about my recent research and
about the number of required follow-up changes to add an incremental upgrade
module for each discovered schema revision as well.

Futhermore, thanks to Jun Omae we utilize a db-specific, non-intrusive query
for retrieving the db table list used in any table existence check from now.

From the beginnung (see [3015]) this plugin's SQL driven schema check relied
on a SELECT raising an exeption for non-existing db table.
This has been discussed lately and found to be a flawed approach, that is even
known to break installations and interferes with db upgrades for Trac 0.13dev
and ultimately Trac 1.0 as well.

After introduction of the db schema version number for this plugin, table
existence testing is required one last time, current schema version is
registered, and only the registered schema version gets checked further on.

TracAnnouncer: Part 1 of 7 - Move towards a versioned db schema for this plugin, refs #5774 and #9742.

Main feature of the code added here:

schema version tracked in system Trac db table

Now we introduce the common, recommended approach of tracking plugin db schema
versions in Trac db table system, that doesn't require any guessing later on.

This changeset requires a database upgrade.

Make sure to backup your db before upgrading, especially if you put faith
into recovering user settings later on. While it may become technically
possible to recover parts of an older configuration, the value of such a
configuration is rather questionable in context of the current feature set,
and I guess that doing a conceptual reinitialization by starting from scratch
is what many (most?) users should consider anyway.

Stand back and wait, at least until it has survived more rigorous testing by
other developers and until enough data migration code has been developed to
preserve critical parts of your Trac applications configuration in production.