Exponentcms Exponent CMS → Release Candidate 1

Comments and changes to this ticket

• 

  dleffler July 16th, 2011 @ 12:27 AM

  • State changed from “new” to “open”
  • Assigned user set to “dleffler”

  This would likely include merging the version check with the install/upgrade check and limiting the version table to a single entry.

• 

  dleffler July 16th, 2011 @ 01:02 PM

  • Title changed from “Investigate moving some version stuff to reference the database table instead of the exponent_version.php file” to “Integrate the version (version table and exponent_version.php file) and upgrade (install) processes”

  Bearing in mind, part of the upgrade process includes checking versions. May require altering the version table to split out version type & iteration for sorting purposes

  • may be able to do away with the “not_configured” file?
  • would probably flow like this:
    • exponent_version.php is the “code” version
    • table exponent_version is the database version
    • if code version < database version, issue warning, but possibly allow continuing?
    • if code version > database version, perform upgrade
    • if code version = database version (or post install/upgrade), set version defines
    • somehow make the “develop” code use more flexible, but not hinder switching back to/from main code line.
• 

  expNinja July 27th, 2011 @ 01:28 AM

  • State changed from “open” to “resolved”

  (from [2bf79edc610616bdef924db4fab751a7608bc538]) Added a version checking process to keep the 'software' and 'database' versions in sync. Now the following things trigger the installation process: 1) install/not_configured exists, 2) conf/config.php does NOT exist, 3) the database version is lower than the software version. Moved version checking methods from subsystem/core.php to expUtil.
  [#217 state:resolved milestone:'Release Candidate 1'] https://github.com/exponentcms/exponent-cms/commit/2bf79edc610616bd...