Upgrade system needs completion

[uaktags]

One of the primary focuses of any application is that your going to create more than a single version and your users are going to have to update their instance. Unfortunately we never had any form of upgrading, it was always a manual process of extracting the files, manually fixing the themes, and manually executing the SQL calls.

Upgrading should be as simple as installing a plugin: Upload the package, say yes, execute, done.

We could go even further and have it be a wizard form like the initial installation, but I don't see it being necessary all the time.

The only problem I worry about is making sure that the upgrade paths are clear. Obviously going from 1.2.1.5 - 1.2.1.6 should be straight forward, but whose to say what may have changed between 1.2.1.5-1.2.1.9. If there's a db realignment somewhere in there, then that needs to be there from that point on. It's really a concern of backward compatibility.

It also brings up the discussion on rules for development: Keep db structure and enduser function changes to a minimal. Major changes like these should result in major version increments.

[deohnas]

I agree. Have you considered semantic versioning?

MAJOR.MINOR.PATCH

which basically means a module MAY only break backward compatibility when doing a major release where minor updates contains new functionality but still functions in backward compatibility manor. And patches are for bug fixes essentially.

Semantic versioning is popular, understandable and easy to work with.

[nachfuellbar]

Maybe using some kind of "delta" upgrades on db? For every change in DB (or for every upgrade with X changes) create one file which is executed if the "database version" isn't reached

Something like db/upgrade/delta/1.2.2.3 db/upgrade/delta/1.2.2.4 db/upgrade/delta/1.2.2.5

And execute 1.2.2.3 only if version < 1.2.2.3 is installed If you upgrade from 1.2.2.2 to 1.2.2.5 this should be executed in sequence 1.2.2.3 then 1.2.2.4 and so on This should ensure a consistent database state

[deohnas]

@nachfuellbar approach are used in frameworks like Wordpress and Drupal and I believe that's a pretty good way to accomplish a update on database state of a module/core.

[JakeBooher]

Going off of what @nachfuellbar said, you don't really need to visit a separate page, just check the DB version, and compare it to the expected DB version (DB version should probably just be a timestamp of when the change was made) then run the changes automatically when viewed from any page. This way people can do deployment magic with github