Portal creation and migration concepts

Since Plone is a constantly evolving system, there is frequently a need to change the initial state of the system. However, to allow people to upgrade between releases, we cannot simply change the portal creation method. Instead, the 'portal_migration' tool is used to provide incremental changes to the base installation. Prior to version 2.5 and the introduction of GenericSetup, when a new Plone Site was created, it would begin at a base version (e.g. Plone 2.0) and then run the migration steps for each release until the most current release. This was done to ensure that migrated and freshly created sites were always in sync. With the introduction of GenericSetup, the state of the Plone site is persisted to XML files found in 'CMFPlone/profiles/default'. When a new Plone site is created (see 'CMFPlone/factory.py') this profile is loaded using the 'portal_setup' tool. However, for users with an older version installed, migrations are run from their current installation to the most recent version. Thus, writing migrations is **vital** when you change Plone in such a way that the base assumptions about what is available change. For example, should you need to add a new tool, this must be created during a migration step to ensure that it is always available. Similarly, when changing actions or default values for properties, adding new properties in portal_properties, adding a depedency on a new product, or changing anything else that becomes part of the "base configuration" in Plone, migrations are needed. In fact, this means that you must make two changes: One to the XML files that set up the site, the other to the migration steps that update existing sites. This is expected to change over time, as GenericSetup becomes even more generic and usable for upgrades, but for now, migrations are necessary. Luckily, changing the base profile XML is quite simple and self-explanatory. Consider the following, which sets up a few properties in 'portal_properties/navtree_properties'::