Re-implement the upgrade mechanism

[VexedPanda]

We really need to get the upgrader working too. And the earlier the better.

[kmeirlaen]

The update relies on a webservice called through the updater script:
 http://release.qcodo.com/update_service/1_0.php/
This service is currently broken as well (permission issue).

We would need access to the files that represent the service. Also, I don't know what license these files have, so we may not be able to use it without permission from MHo.

[VexedPanda]

Hopefully we can figure out a replacement method.

I don't expect we can force QCodo to update itself to QCubed, we just need QCubed v1.0.0 to upgrade to later versions.

[MikeHostetler]

Pushing this off from RC2. The Upgrader will become deprecated and removed.

[VexedPanda]

We still need an upgrader to allow users to grab core changes without overwriting customized files. Re-adding to 1.0.0

[alex94040]

I'm not convinced that we need this for 1.0. We'll be reworking the directory structure completely in the future, I see no need to invest time into this now - it would be throw-away work

[VexedPanda]

It would allow people with 1.0.0 to upgrade to future versions without massive amounts of pain. The biggest reason I'm still not running RC2 on production is simply that applying the change is too painful.

We need a program that will upgrade only changed files, and allow me to go through each file that has changed on both ends, and approve things on a change-by-change basis. Ideally, it would have a built in merging app so that we can apply any customizations I have made with the new changes in core.

If _I_ as a core developer am avoiding upgrading due to no easy upgrade tool, I can't imagine it will be any better received by other end users. And ensuring they can run the newest version, with the associated bug fixes is going to be important to our success as a framework.

If we absolutely have to postpone it, 1.1.0 would need to include the tools required to upgrade in such a manner from 1.0.0, so any pathing changes, etc would have to be figured out anyhow. Getting something in place now, therefore, shouldn't take any additional work in the long run.

[basilieus]

Vex:

That can also signal to us that the file structure for the application is not in its ideal situation.

[VexedPanda]

Well, somewhat. We're generally pretty good about seperating base and overridable classes. I'm just not personally that good at leaving the base files alone. :P This is mostly due to the lack of overrides for some of the more framework-centric files like QQNode.class.php. This seems justified though, since really we shouldn't need to override QQNode.class.php. Eventually, I hope all my customizations to be adopted into core so that I'm no longer encountering these particular kinds of upgrade issues.

[MikeHostetler]

I'm postponing this. I realize it's not ideal that this feature is lost, but there's not a lot of interest in building it, as most developers either use SVN or download a release.

If I'm wrong, please speak up.

[VexedPanda]

We could steal what QCodo is currently using.

Some related changes here:
 http://github.com/qcodo/qcodo/commit/09cd2e1163f55f611c5c641ebd9ae16a248bf89f

[VexedPanda]

 http://github.com/qcodo/qcodo/commit/bb7ff26e89fcebda49e0b6e442eb8e6c2c5f5819