| | 1 | The plan is to extend the online udpate system to be able to update both the core ''module'' as well as ''framework'' code which is all the parts of freepbx that are not located in the module directory. The current plan is as follows.[[BR]] |
|---|
| | 2 | |
|---|
| | 3 | '''Core'''[[BR]] |
|---|
| | 4 | Moving Core from its current location to the module repository mostly works today. There are some indirect expectations that core is installed and available by the ''framework,'' such as AUTHTYPE=database mode which uses the ampuser table to lookup users, and that table is accessed by one of the ''core module'' components. There are ways around this such as forcing a virgin install to be in AUTHTYPE=none which effectively it is anyhow since there are no users created yet. |
|---|
| | 5 | |
|---|
| | 6 | However, bringing up a system without Core installed can get a bit confusing to the user, so the ideal situation is to install with Core included, but yet have it upgradable through the Online system. This is the planned route. We will Achieve this by allowing Core to be housed in the module repository but package it with the tarball during an initial install. That process is described after intoducing ''framework.'' |
|---|
| | 7 | |
|---|
| | 8 | We will also move several conf and script files to core. These include extensions.conf, sip.conf, iax.conf, dialparties.agi, fixlocalprefix, etc. Once placed in the proper directory there is an existing mechanism that auto-links these files to their appropriate place as part of the installation process. These can then be updated with bug fixes by upgrading ''core''[[BR]] |
|---|
| | 9 | |
|---|
| | 10 | '''Framework'''[[BR]] |
|---|
| | 11 | In addition to ''Core'' there is the ''Framework'' code which includes all the FreePBX web code required to make core function, in addtion to other key components such as ''retreive_conf'' and various other parts. In order to provide a facility to upgrades these components, we will introduce a new module called ''framework'' that will serve the purpose of installing patches to any needed files. The module itself will be nothing more than a module.xml file and an install.php script. The module's actual contents will be generated any time ''publish.pl'' is exectuted from the ''framewok'' module. It will be packaged as part of the module tarball but will not be checked in to svn. At publish time, the following will occur:[[BR]] |
|---|
| | 12 | {{{ |
|---|
| | 13 | PSEUDO CODE: |
|---|
| | 14 | // $fwbranch represents the current branch we are in. |
|---|
| | 15 | // $framework is the name of the module |
|---|
| | 16 | // |
|---|
| | 17 | // Note there are several files such as extensions.conf, sip.conf, iax.conf, agi scripts, etc. |
|---|
| | 18 | // that are moved to the core module already and will be auto linked by retrieve_conf and handled by |
|---|
| | 19 | // Core as appropriate. This provides an example, it is not final. |
|---|
| | 20 | // |
|---|
| | 21 | rm -rf $framework/agi-bin $framework/bin $framework/htdocs |
|---|
| | 22 | svn export https://svn.sourceforge.net/svnroot/amportal/freepbx/$fwbranch/amp_conf/agi-bin $framework/agi-bin |
|---|
| | 23 | svn export https://svn.sourceforge.net/svnroot/amportal/freepbx/$fwbranch/amp_conf/bin $framework/bin |
|---|
| | 24 | svn export https://svn.sourceforge.net/svnroot/amportal/freepbx/$fwbranch/amp_conf/htdocs $framework/htdocs |
|---|
| | 25 | rm -rf $framework/recordings/includes/main.conf.php |
|---|
| | 26 | }}} |
|---|
| | 27 | As a result of these files being exported, the framework module now has copies of the most recent code which inevitably includes some bug fixes (or it wouldn't be published). The ''install.php'' script is aware of this file structure and simply moves forward when a new update is executed and copies the various files to their required location.[[BR]] |
|---|
| | 28 | |
|---|
| | 29 | '''Release Tarball Generation'''[[BR]] |
|---|
| | 30 | The tarball packaging process needs some minor modification, it will proceed as follows:[[BR]] |
|---|
| | 31 | * Set the ''core'' and ''framework'' version numbers to: ''main_release_number''.0 |
|---|
| | 32 | * Set the dependency of that module to the ''main_release_number'' |
|---|
| | 33 | * Make sure the modules are checked-in |
|---|
| | 34 | * Go through normal steps up to where the tag is created as outlined in [wiki:FreePbxRelease Preparing for a tarball release]. |
|---|
| | 35 | * Do an svn copy of ''core'' and ''framework'' into the tag (under ''amp_conf/htdocs/admin/modules'') |
|---|
| | 36 | * proceed with the normal packaging[[BR]] |
|---|
| | 37 | |
|---|
| | 38 | Doing the svn copy of ''core'' and ''framework'' into the tag will resut in the proper tarball being generated since it comes from the tag. Note that framework doesn't actually include anything but the ''install.php'' and ''module.xml'' script so there is not real content generated from it. The real ''framework'' is actually in the tarball. |
|---|
| | 39 | |
|---|
| | 40 | '''install_amp implications'''[[BR]] |
|---|
| | 41 | The scenario that has to be addressed and thus handled by ''install_amp'' is someone who had upgraded a system through the module admin, and then goes back and does a reinstall of the tarball. In that instance, ''framework'' has its ''shell'' (''module.xml'' and ''install.php'') installed as part of the tarball but the actuall tarball has older versions of framework code installed potentially. Also, older 'core'' module code may be included in the tarball. This means that the installation is going backwards from potential ''framework'' and ''core'' online updates that may already have been done and reflected in the database. In order to handle this case, ''install_amp'' will be modified to check both ''core'' and ''framework'' within the tarball, and if found it will reset the version number, as well as enable, both of these modules so that the system will be set correctly and the online system will allow it to pull upgrades again. |
|---|
| | 42 | |
|---|
| | 43 | If installing direct from svn, a system will not have these two modules so install_amp will not change the version number and it will remain proper.[[BR]] |
|---|
| | 44 | |
|---|
| | 45 | '''Using Framework and Core Online Updates'''[[BR]] |
|---|
| | 46 | Discretion will be taken using this new upgrade system since both Framework and Core are critical to the functioning of the system. Furthermore, this upgrade mechanism is not designed to handle schema changes. Such changes should not be needed as they usually imply new features which should not be introduced through such a system. Any big changes of this sort should be done with a new tarball release. And within a branch, once stable (post beta/rc programs) - new features should not be introduced anyhow. |
|---|
