Updater
Posted by Digitalxero on 2009-07-28 01:34
Snowdog and I were talking via e-mail about the planned updater and it's reliance on Mercurial and the conclusion is this reliance needs to drop and we need to go back to an updater similar to the one in version 1.7.3, but with some improvements.
Now one of the major reasons I abandon this updater system in the first place was it was a PITA to perform a release. So we need to develop a release manager that has the following attributes
- Dont compute the hash of each file every time you check to see what needs to be updated. Each release should come with a release.xml file that has the hash precomputed in it.
- Provide a method for advanced users to tell the updater to ignore certain files. I think a updater.ignore file with 1 file per line will work well for this
Now one of the major reasons I abandon this updater system in the first place was it was a PITA to perform a release. So we need to develop a release manager that has the following attributes
- Simple command line tool and it does everything that is required
- Supports making a new major release (1.8.0 to 1.8.1)
- Supports replacing a release with a new incremental release (1.8.0 to 1.8.0.1)
- Supports depreciating a release (This would cause the updater to not list it)
- Supports branched releases (Stable, Beta, Dev) so if certain users want more bleeding edge code they can get it ???
- Server for hosting releases needs to be controlled by the dev team not a single developer
- Snowdog recommended Sourceforge for this, since there is 'unlimited' file space available on openrpg's site on sourceforge and they have automatic multiple backup mirroring for files. But there are two issues with this
- The mirroring of files is only done when a file is manually uploaded via the web interface, so that restricts us to using the projects web space for this.
- The SF web space servers are slow, this why the meta was moved off of them to the openrpg.com server years ago
- Amazon S3. This is an attractive option, but costs money (prob $1.00 or less per month) and you, as far as I know, cannot prepay
- Snowdog recommended Sourceforge for this, since there is 'unlimited' file space available on openrpg's site on sourceforge and they have automatic multiple backup mirroring for files. But there are two issues with this
Home / Developer API / Tour / Get a Project - Solutions for Bug & Issue Tracking, Collaboration Tools, Subversion Hosting, Git Hosting
Openrpg is powered by Assembla.
5 Comments
By sirebral on 2009-07-29 18:44
This is the route I am going: http://www.assembla.com/spaces/traipse/tickets/3-Easy-update-window
With this design users will download their files every time they run the software, then the software will check which updates are available, and the user will be able to update to any branch and any revision within that branch.
Maybe you guys want to rethink your update process.
By Digitalxero on 2009-07-30 05:38
Repository
Dependencies:
Usage
<type> can be stable, beta, dev
python rm.py make <type> #.#.#
-This will create a new release of specified type and branchpython rm.py increment <type> #.#.#
- This will do an incremental release of the specified type and branchpython rm.py remove <type> #.#.#
- This will remove a releaseSettings
None of the settings are required in your settings.py file
By davidbyron on 2009-07-31 17:48
This is another example of a simple mod to the program that gets wiped out currently in 1.7.7 / 8
Ideally the updater could auto-merge it (because it's likely we won't change the same file) but failing that we need an easy way to say "don't update" through the UI -- like the no update setting used to be -- and preferably the no-updater clients would get reminders every now and then about what they are missing.
By sirebral on 2009-08-01 23:45
By separating OpenRPG the way you are with your planned updater, users will have a harder time with development. Users should be encouraged to clone a repo, do their own deving with it, and then share the repo so others can get the updates with the Update Manager.
See how this was panning out on my side now, Snowdog? I had this all planned, but instead of working on a simple Update Window Dj decided to work on entire new installation procedure. It's a bad idea.
By Digitalxero on 2009-08-02 08:39