Kaju self-updater talk (v.1.x)

The French translation and all other bug fixes, etc., are in the develop branch now.

I’ll probably roll that into a new release soon, but I’ll hold off if you (or someone) wants to do Spanish. Again, apply any translations to the “Translation” branch please.

@Kem Tekinay I only know a little Spanglish and it is very bad. I was just curious.

np, I’ll roll what I have into a release later.

We have some good Spanish speaking natives here. They will probably show up eventually.

Version 1.2 has been posted.

https://github.com/ktekinay/Kaju

I can make the translation, but I don’t know how to use github (and don’t have the time to learn right now).

What do I need to do?

Create a GitHub Account (Free) and install the GitHub Client.
Click on the “Clone to Desktop” Link on the Poject Page and then create your own “Fork” by clicking on “Create new Fork”(?) in the GitHub client.

Work in your Fork and afterwards Commit+Sync your Fork by using the GitHub client again.

Go to the GitHub page and request a “Pull” (the green Button with circling arrows) between your Fork and the “translation” Fork.

Please excuse this short explanation but i have no access to all this stuff while i am at my office :frowning:

BTW: I also don’t know what i am doing here, but it works… :wink:

Thanks Sascha. I’ll try.

I had already downloaded the project and started the translation, but I will do as you say.

Julen

I have the translation but I don’t see how to create a new fork, commit, pulll, … etc. And I can’t spend time trying to figure this out, sorry.

This is the file: https://dl.dropboxusercontent.com/u/3800071/KajuLocale.xojo_code

Julen.

While I encourage you to learn about using GitHub, I can work with that file in this case.

Thanks for your help.

v.1.2.1 has been pushed.

Thanks Kem.

Looking at the available International Channels, what’s left is:

  1. Italian
  2. Portugese
  3. Dutch
  4. Japanese
  5. Chinese

I’ve ranked these by the number of conversations in each channel.

I’m going to be making a slight change to how versions are displayed and converted to doubles for comparison.

Right now, if that app or version is in “Final” stage, the “non-release version” is ignored. I did this because I often forget to reset that number when releasing a final, but @Jeremy Cowgar pointed out that developers will use that in the form “1.1.0 build 654”, or “1.1.0 (654)”, or something along those lines. As such, there should be a way for Kaju to compare and present that to the user, so I will enable that.

My preference is “x.y.z (ddd)”, and I really don’t want to go down the road of making this a preference of some sort. Comments?

(To be clear, when the non-release version for a final is 0, the behavior will be unchanged from today.)

Sounds fine to me…

I just found that two of the translations were marked as “default” instead of their languages, so some messages will show up in either German or French in other locales. Please wait for 1.3 (posting soon) to update.

I just posted v.1.3. This fixed the above-mentioned translations and recognizes version numbers like “1.1 (45)” or “1.2.3 (23)”.

Note: If you decide to use the build numbers in the final and you have version out there that already uses pre-1.3 Kaju, you must start a new update line. Otherwise, the older version will not understand the build number and give the user an error.

Fortunately, Kaju is new enough that this shouldn’t be a big issue.

https://github.com/ktekinay/Kaju

A “dupe” is not enough, we need to create a complete new update (= also a new RSA), correct?

No, you can use the same file. For example, let’s say you release v.1.0 with Kaju 1.1. In the update file, enter information for the new 1.1 (with Kaju 1.3) and export to /old/update/url/. But version 1.1 will look to /new/update/url/ for its update information, so export to there too.

In the future, only update the info at /new/update/url/. It means someone using v.1.0 will get information about v.1.1 only, will have to update to that, then see information about newer versions.

I don’t anticipate this happening too much (or ever again), so I’m comfortable with that workaround.

Another bug just came to light in MinimumRequiredVersion. It turns out that you need to spell these things consistently… At any rate, I’ll push an update soon.