Auto-Updater/Launcher?

[Longor1996]

We should try to write a Auto-Updater or Launcher for Paint.JAVA, or something that can tell the user that a new version is out.

I don't have the time, nor internet-bandwidth to work on something like this a lot.

[HeroesGrave]

I have code for it, but I'm not sure we really want to go into launcher stuff. I want this to be reasonably lightweight.

Checking if a new update is out is fine though.
Maybe put something under the help/info menu.

It could just be downloading a version.txt from the repository and checking if it matches.

I'm going to put off a final decision until just before 1.0

(As another thought, maybe we could make a plugin for it?)

[Longor1996]

Making a Plugin for it may be a good Idea. By doing so we can actually have our first Plugin to show off, and others can copy it (open-source) and use it as a base.

[HeroesGrave]

I tried making a plugin tutorial in the wiki, but a) I'm lazy and did the bare minimum, and b) I'm lazy and can't be bothered updating it to the current plugin API.

[william-reed]

I am considering taking on this task. If it is an auto updater it would need another jar to tell the user whats going on while the new jar for the Paint.JAVA is being downloaded. Would this be something desirable or did you have another method in mind?

[HeroesGrave]

I haven't really decided on how this will work, and it's probably better to wait until after the 1.0 release so we can finalize the setup of the builds etc.

[BurntPizza]

I think at least having a system to check if there is a new version available should be a 1.0 feature. Maybe just check github/master branch version or release number/date? Then display a splash or something.

Either way, here's info regarding java auto update stuff: http://stackoverflow.com/questions/4002462/how-can-i-write-a-java-application-that-can-update-itself-at-runtime

[HeroesGrave]

The question is, can we do it without bootstrapping?

[HeroesGrave]

Answer: Sort-of.

Give the plugin jar double functionality. One as a plugin, one as a sort-of bootstrapper.

When you select update or whatever, it runs the updater as a new process, exits Paint.JAVA, and then restarts Paint.JAVA when it's done.

[BurntPizza]

Might necessitate 2 jars, which isn't really a big deal, but then we pretty much are moving right along to a full installation directory

[HeroesGrave]

If anyone wants to make a plugin for this, go ahead. Even if it's not perfect, we can use it as a temporary solution.

[BurntPizza]

Is there a good way to create to 1. create a jar file at runtime from precompiled classes, and 2. run it in a new JVM from an already running JVM. I know 1 is a yes, but no. 2 might be more tricky for portability reasons.

[HeroesGrave]

Ah, whatever.

I'll work on this now to get it out of the way.

Assigned myself.

[william-reed]

One way I have seen this done before is to store a file in the repo containing the version number and the jar file. If the release was 0.0.2 and the client had version 0.0.1 it would open the updater and download the new jar then re launch Paint.JAVA. pretty simple concept. Requires some threading to keep the user updates but nothing too hard. On Feb 15, 2014 6:19 PM, "HeroesGrave" notifications@github.com wrote:

I haven't really decided on how this will work, and it's probably better to wait until after the 1.0 release so we can finalize the setup of the builds etc.

Reply to this email directly or view it on GitHubhttps://github.com/HeroesGrave/Paint.JAVA/issues/38#issuecomment-35171190 .

[HeroesGrave]

Okay, I've written a basic auto-updater plugin.

It actually works quite smoothly.

The only problem is it's designed to work for stable versions, so if you have a beta or dev, it won't update. This means that a) it can't be used properly yet, and b) after 1.0, if you have a dev build or beta it won't auto-update.

The alternative is to request an update anyway, but then that will cause problems for those using builds that aren't on the master branch, as it will keep asking to update even though you may have the latest version.

Two choices:

1. Have two plugins. One for 'dev' branch, and one for 'master'.
2. Have one plugin, but then have to deal with configuration to allow choosing between dev and master branch.
3. Change the versioning system for dev builds so it always changes. This is a pain, as I have to remember to update it.
4. Don't allow auto-updating for dev builds. Create a beta branch post-1.0 and then allow switching between betas and stables.

[HeroesGrave]

I like idea 4 the best, so I'm going to go with that.

I'll release the auto-updater anyway, but with no 'stables' coming anytime soon (until 1.0), it won't do much.

This plugin will not work with dev builds, as it will keep asking you to update to latest master.

[BurntPizza]

Yeah, I'm of the mind that dev shouldn't auto-update, because it does so rapidly, and can break stuff when it happens.

Also, is this a patch system, or a full redownload entire app each time? (I know it's only ~280 Kb, but that can change)

[HeroesGrave]

It's a full download.

Unlike most other applications written in C/C++/Whatever, most of the code is part of the JVM so the downloads should remain quite small.

[HeroesGrave]

Pushed out 1.0-Beta.1 to make sure everything is working.

It seems pretty much stable.

I'm just waiting to see what's going to happen with #49 before going to 1.0

[HeroesGrave]

Closed. You can get the plugin here.