Child pages
  • [install] Changing way, how upgrade scripts are stored [5.3.0-B1]
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/d9caf9c64a04cd6b#

Right now In-Portal has upgrades.php and upgrades.sql files in each module, that can be upgraded. Over time we got a lot of code there that is only executed once, but distracts attention from actual last upgrade script code that needs to be written.

I'm proposing, that we return to upgrade script storage system, like it was in 4.2.0 and earlier versions of In-Portal: one file per version:

  • upgrade_5.2.0-B3.sql and  upgrade_5.2.0-B3.php and so on

Using php build-in function "version_compare" we can easily sort these files. But this time let's place these files in install folder sub-folder and not in install folder itself, like it was done in 4.2.0 and before.

Related Discussions

Related Tasks

INP-1078 - Getting issue details... STATUS

8 Comments

  1. Hi Alex,

    I like the idea and ready to support this.

    The only down side is that we might need to have some sort of common PHP
    file which can share some code between upgrades or perhaps not - you what
    you think?

    DA

  2. We already have this file: kUpgradeHelper class, that is common ancestor to
    all php upgrade scripts (in all modules). Now it would be also a common
    ancestor to different version php scripts within one module aswell.

    On Sat, Jun 2, 2012 at 2:49 AM, Dmitry A. <dandre...@gmail.com> wrote:
    > Hi Alex,

    > I like the idea and ready to support this.

    > The only down side is that we might need to have some sort of common PHP
    > file which can share some code between upgrades or perhaps not - you what
    > you think?

    > DA

  3. Great! Then I am for it with my both hands!

    DA

  4. Here is the task:

    INP-1078 - Getting issue details... STATUS


    On Sun, Jun 3, 2012 at 8:39 AM, Dmitry A. <dandre...@gmail.com> wrote:
    > Great! Then I am for it with my both hands!

    > DA

  5. Another positive side effect - during merging from bugfix branch into
    feature branch there won't be conflicts in upgrades.sql and upgrades.php
    files like now, because each version is separately added file.

    I'm recommending not to wait too long before implementing that, because
    currently /core/install/upgrades.sql is already 161KB long, which is twice
    larger, then average PHP file in In-Portal.

  6. I have moved this task to In-Portal 5.3.0.

    I believe it deserves our attention.

    DA